Чи є різниця в ефективності між CTE, підзапитом, тимчасовою таблицею або змінною таблиці?

У цьому відмінному SO питання , відмінності між CTEі sub-queriesбули обговорені.

Я хотів би спеціально запитати:

За яких обставин кожен із наступних є більш ефективним / швидшим?

• CTE
• Підзапит
• Тимчасовий стіл
• Змінна таблиця

Традиційно я багато використовував temp tablesу розробці stored procedures- тому що вони здаються читабельнішими, ніж багато переплетених підзапитів.

Non-recursive CTEs інкапсулювати набори даних дуже добре та добре читаються, але чи існують конкретні обставини, коли можна сказати, що вони завжди матимуть кращі результати? чи це випадок, коли вам доведеться завжди обходитися з різними варіантами, щоб знайти найбільш ефективне рішення?

EDIT

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

SQL - це декларативна мова, а не процедура. Тобто ви будуєте оператор SQL для опису результатів, які ви хочете. Ви не говорите двигуну SQL, як робити роботу.

Як правило, це гарна ідея дозволити SQL-механізму та оптимізатору SQL знайти найкращий план запитів. Багато людей-років намагаються вкластись у розробку двигуна SQL, тому нехай інженери роблять те, що вміють робити.

Звичайно, бувають ситуації, коли план запитів не є оптимальним. Потім потрібно використовувати підказки для запитів, реструктурувати запит, оновлювати статистику, використовувати тимчасові таблиці, додавати індекси тощо, щоб отримати кращу ефективність.

Щодо вашого питання. Продуктивність CTE та підзапитів теоретично повинна бути однаковою, оскільки обидва надають однакову інформацію оптимізатору запитів. Одна відмінність полягає в тому, що CTE, що використовується більше, ніж один раз, можна було легко визначити та обчислити один раз. Потім результати можна зберігати і читати кілька разів. На жаль, SQL Server, схоже, не користується цим базовим методом оптимізації (ви можете назвати це загальне усунення підзапиту).

Тимчасові таблиці - це інша справа, оскільки ви надаєте більше вказівок щодо того, як слід проводити запит. Одна з головних відмінностей полягає в тому, що оптимізатор може використовувати статистику з тимчасової таблиці для встановлення свого плану запитів. Це може призвести до підвищення продуктивності. Крім того, якщо у вас є складний CTE (підзапит), який використовується не один раз, його зберігання у тимчасовій таблиці часто сприятиме підвищенню продуктивності. Запит виконується лише один раз.

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

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

Звичайно, є випадки, коли ви можете розгадати CTE або видалити підзапити та замінити їх таблицею #temp та зменшити тривалість. Це може бути пов'язано з різними речами, такими як статична статистика, неможливість навіть отримати точні статистичні дані (наприклад, приєднання до функції, що оцінюється за таблицею), паралелізм або навіть неможливість створення оптимального плану через складність запиту ( в такому випадку розбиття його може дати шанс оптимізатору на боротьбу). Але також бувають випадки, коли введення-виведення, пов'язане зі створенням таблиці #temp, може переважувати інші аспекти продуктивності, які можуть зробити певну форму плану за допомогою CTE менш привабливою.

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

Тому я б запропонував написати запит таким чином, який вам здається найбільш природним, і відхилятися лише тоді, коли ви виявите проблему з ефективністю роботи оптимізатора. Особисто я класифікую їх CTE, а потім запит, в останню чергу використовую таблицю #temp.

#temp матералізований, а CTE - ні.

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

Деякі люди на SO, яким не подобаються змінні таблиці, але мені подобається, що вони матеріалізуються і швидше створюються, ніж #temp. Бувають випадки, коли оптимізатор запитів робить краще з #temp порівняно зі змінною таблиці.

Можливість створення ПК на #temp або таблиці змінної дає оптимізатору запитів більше інформації, ніж CTE (оскільки ви не можете оголосити PK на CTE).

Тільки дві речі, на які я думаю, завжди дозволяють використовувати # Temp Table, а не CTE:

1. Не можна ставити первинний ключ на CTE, тому дані, до яких звертається CTE, повинні будуть перетинати кожен з індексів у таблицях CTE, а не просто отримувати доступ до ПК або Індексу в таблиці темпів.

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

-одні вчора

Ось приклад, коли обмеження #table можуть запобігати появі помилкових даних, що не стосується CTE

DECLARE @BadData TABLE ( 
                       ThisID int
                     , ThatID int );
INSERT INTO @BadData
       ( ThisID
       , ThatID
       ) 
VALUES
       ( 1, 1 ),
       ( 1, 2 ),
       ( 2, 2 ),
       ( 1, 1 );

IF OBJECT_ID('tempdb..#This') IS NOT NULL
    DROP TABLE #This;
CREATE TABLE #This ( 
             ThisID int NOT NULL
           , ThatID int NOT NULL
                        UNIQUE(ThisID, ThatID) );
INSERT INTO #This
SELECT * FROM @BadData;
WITH This_CTE
     AS (SELECT *
           FROM @BadData)
     SELECT *
       FROM This_CTE;