Приєднання SQL Server / де замовлення на обробку

Прочитавши Slow SQL-запит, не знаючи, як оптимізувати , це змусило мене замислитися про загальну ефективність запитів. Безумовно, нам потрібні результати першої таблиці (коли об’єднуються інші таблиці) перед тим, як приєднатися (внутрішні приєднання до цього питання), щоб вони були максимально дрібними, щоб зробити наші запити, які крихітні трохи, швидше.

Приклад, якщо це:

SELECT *
FROM   ( SELECT * FROM table1 WHERE col = @val ) t
INNER JOIN table2 ON col = col2

Будь краще / швидше, ніж:

SELECT *
FROM table1
INNER JOIN table2 ON col = col2
WHERE table1.col = @val

Моя теорія полягає в наступному (це може бути не правильною реалізацією, я намагаюся запам’ятати із книги, яку я читав із внутрішніх систем SQL Server 2008 (MSFT Press)):

1. Процесор запитів спочатку отримує ліву таблицю (table1)
2. Приєднується до другої таблиці (table2) і формує декартовий продукт до фільтрування необхідних рядків (якщо це застосовується)
3. Потім виконує пропозиції WHERE, ORDER BY, GROUP BY, HAVING із заявою SEELCT.

Отже, якщо у викладі №1 вище таблиця менша, SQL-двигуну доводиться менше працювати при формуванні декартових продуктів. Потім, коли ви дістанете оператор where, у вас є зменшений набір результатів, з якого слід фільтрувати в пам'яті.

Я міг би бути настільки далеко, що це нереально. Як я вже казав, це теорія.

Ваші думки?

Примітка . Я тільки що думав над цим питанням і ще не мав шансів запустити будь-які тести.

Примітка 2 : Мічений , як SQL Server , так як я не знаю нічого про здійснення MySql і т.д. ласка , чи не соромтеся відповідь / коментар в будь-якому випадку

Логічна обробка запиту відбувається на MSDN (написана командою Microsoft SQL Server, а не третіми сторонами)

1. FROM
2. ON
3. JOIN
4. WHERE
5. GROUP BY
6. WITH CUBE or WITH ROLLUP
7. HAVING
8. SELECT
9. DISTINCT
10. ORDER BY
11. TOP

З цього випливає виведена таблиця, тоді зовнішній запит робить це знову і т. Д. І т.д.

Це логічно : не актуально . Незалежно від того, як насправді це робить SQL Server, ця семантика шанується на письмі . "Фактичний" визначається оптимізатором запитів (QO), і ви уникаєте проміжного продукту Cartesion, який ви згадали.

Варто зазначити, що SQL є декларативним: ви говорите "що" не "як", як би ви зробили для процедурного / імперативного програмування (Java, .net). Так що сказати «це відбувається раніше» в багатьох випадках помилково (наприклад, припущення про коротке замикання або замовлення L-to-R де)

У вашому випадку вище, QO генерує той самий план незалежно від того, як він структурований, оскільки це простий запит.

Однак QO ґрунтується на витратах, і для складного запиту може знадобитися 2 тижні, щоб створити ідеальний план. Отже, це "досить добре", що насправді не є.

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

Я використовував цю хитрість на SQL Server 2000, щоб отримати 60-кратну швидкість роботи над запитами звітування. Оскільки QO вдосконалює версію до версії, вона стає кращою при розробці цих речей.

І книга, яку ви згадали: існує певна суперечка щодо неї.
Див. ТА ТА наступні посилання: /programming//q/3270338/27535

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

Ви начебто оцінюєте два варіанти, які може врахувати оптимізатор запитів під час створення плану для цього запиту. Основним фактором, який впливає на вибір плану, є статистика для відповідних таблиць та витрати, пов'язані з вибором оператора в будь-яких планах-кандидатах.

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

Іноді це неправильно, і ви можете допомогти йому зробити кращий вибір шляхом покращення індексації, оновлюючи статистику та застосовуючи підказки. У дуже рідкісних випадках ви можете змусити примусити виконувати порядок виконання, використовуючи підказку FORCE ORDER, але це слід застосовувати ощадно. Це молоток для розламування горіха, оптимізатор, як правило, може намагатися створювати кращі плани, подаючи кращу інформацію.