Підзапроси проти приєднується

Я відновив повільний розділ програми, яку ми отримали у спадок від іншої компанії, щоб використовувати внутрішнє з'єднання замість підзапиту типу:

WHERE id IN (SELECT id FROM ...)

Повторно налаштований запит працює приблизно в 100 разів швидше. (~ 50 секунд до ~ 0,3) Я очікував на покращення, але хтось може пояснити, чому це було так різко? Стовпці, що використовуються в пункті, де всі були індексовані. Чи виконує SQL запит у пункті де раз на рядок чи щось таке?

Оновлення - Поясніть результати:

Різниця полягає у другій частині запиту "де id in ()" -

2   DEPENDENT SUBQUERY  submission_tags ref st_tag_id   st_tag_id   4   const   2966    Using where

vs 1 індексований рядок з приєднанням:

    SIMPLE  s   eq_ref  PRIMARY PRIMARY 4   newsladder_production.st.submission_id  1   Using index

"Корельований підзапит" (тобто такий, у якому умова, де залежить від значень, отриманих із рядків запиту, що містить), буде виконуватися один раз для кожного рядка. Некорельований підзапит (той, у якому умова, де умова не залежить від містять запит) буде виконуватися один раз на початку. Двигун SQL робить це розрізнення автоматично.

Але, так, план-пояснення дасть вам брудні деталі.

Ви виконуєте підзапит один раз для кожного рядка, тоді як об'єднання відбувається в індексах.

Ось приклад того, як оцінюються підзапити в MySQL 6.0 .

Новий оптимізатор перетворить цей вид підзапитів у приєднання.

Запустіть план пояснення на кожній версії, він підкаже, чому.

перед запуском запитів до набору даних, вони ставляться через оптимізатор запитів, оптимізатор намагається організувати запит таким чином, щоб він міг видалити стільки кортежів (рядків) з набору результатів якнайшвидше. Часто, коли ви використовуєте підзапити (особливо погані), кортежі не можна вирізати з набору результатів, поки зовнішній запит не почне працювати.

Не побачивши запиту, важко сказати, що було так погано в оригіналі, але я гадаю, що це було те, що оптимізатор просто не міг зробити набагато кращого. Запуск "Пояснення" покаже вам метод оптимізаторів для отримання даних.

Подивіться план запитів кожного запиту.

Де вхід і приєднання зазвичай можуть бути реалізовані за допомогою одного і того ж плану виконання, тому зазвичай між ними змінюється нульова швидкість.

Оптимізатор зробив не дуже гарну роботу. Зазвичай вони можуть бути перетворені без різниці, і оптимізатор може це зробити.

Зазвичай результат його оптимізатора не в змозі зрозуміти, що підзапит може бути виконаний як об'єднання, і в цьому випадку він виконує підзапит для кожного запису в таблиці, а не приєднується до таблиці в підзапиті проти таблиці, яку ви запитуєте. Деякі з більш «підприємливих» баз кращі в цьому, але іноді вони все-таки сумують.

Це питання дещо загальне, тому ось загальна відповідь:

В основному, запити займають більше часу, коли MySQL має багато рядків для сортування.

Зробити це:

Запустіть ПОЯСНЕННЯ про кожен із запитів (JOIN'ed, потім Subqueried) та опублікуйте результати тут.

Я думаю, що побачити різницю в інтерпретації MySQL цих запитів було б досвідом навчання для всіх.

Підзапит де повинен виконувати 1 запит для кожного повернутого рядка. Внутрішнє з'єднання просто має виконати 1 запит.

Підзапит, ймовірно, виконував "сканування повної таблиці". Іншими словами, не використовуючи індекс і не повертаючи занадто багато рядків, які Де з головного запиту потрібно було фільтрувати.

Просто здогадка без деталей, звичайно, але це звичайна ситуація.

За допомогою підзапиту вам потрібно повторно виконати 2-й SELECT для кожного результату, і кожне виконання, як правило, повертає 1 рядок.

При об'єднанні 2-й SELECT повертає набагато більше рядків, але виконувати його потрібно лише один раз. Перевага полягає в тому, що тепер ви можете приєднатись до результатів, а з'єднання відносин - це те, в чому база даних повинна бути хорошою. Наприклад, можливо, оптимізатор може визначити, як краще скористатися індексом зараз.

Це не стільки запит, скільки пункт IN, хоча приєднання лежать в основі принаймні SQL-двигуна Oracle і працюють надзвичайно швидко.

Взяте з Довідкового посібника ( 14.2.10.11 Переписування підзапитів як приєднання ):

ПРИЄДНАЙТЕСЬ ЛІВО [ВАРТУ] може бути швидше, ніж еквівалентний підзапит, оскільки сервер, можливо, зможе краще оптимізувати його - факт, який не характерний лише для MySQL Server.

Таким чином, підзапити можуть бути повільнішими, ніж ЛІВНІ [ВАРІНТИ] ПРИЄДНАЄТЬСЯ.