SQL приєднується до протизапитів SQL (продуктивність)?

Я хочу знати, чи є у мене запит на приєднання щось подібне -

Select E.Id,E.Name from Employee E join Dept D on E.DeptId=D.Id

і підпиту щось подібне -

Select E.Id,E.Name from Employee Where DeptId in (Select Id from Dept)

Коли я розглядаю ефективність, який із двох запитів був би швидшим і чому ?

Чи є час, коли я повинен віддавати перевагу одному перед іншим?

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

Я б очікував, що перший запит буде швидшим, головним чином тому, що у вас є еквівалентність і явна ПРИЄДНАЙТЕСЬ. На мій досвід IN, це дуже повільний оператор, оскільки SQL зазвичай оцінює його як ряд WHEREпропозицій, розділених "АБО" ( WHERE x=Y OR x=Z OR...).

Як і у ВСІХ ЧАСАХ SQL, проте пробіг може відрізнятися. Швидкість буде багато залежати від індексів (чи є у вас індекси в обох стовпцях ідентифікаторів? Це дуже допоможе ...) серед іншого.

Єдиний РЕАЛЬНИЙ спосіб сказати зі 100% впевненістю, що швидше, - увімкнути відстеження ефективності (особливо корисна інформація IO) та запустити їх обох. Не забудьте очистити кеш-пам'ять між прогонами!

Ну, я вважаю, це "старе, але золото" питання. Відповідь: "Це залежить!". Виступи є настільки делікатною темою, що було б занадто нерозумно сказати: "Ніколи не використовуйте підзапити, завжди приєднуйтесь". У наступних посиланнях ви знайдете основні найкращі практики, які я вважаю дуже корисними:

• Оптимізація запитів
• Оптимізація запитів за допомогою трансформацій Semijoin
• Переписування запитів як приєднання

У мене є таблиця з 50000 елементами, результат, який я шукав, - 739 елементів.

Спочатку мій запит:

SELECT  p.id,
    p.fixedId,
    p.azienda_id,
    p.categoria_id,
    p.linea,
    p.tipo,
    p.nome
FROM prodotto p
WHERE p.azienda_id = 2699 AND p.anno = (
    SELECT MAX(p2.anno) 
    FROM prodotto p2 
    WHERE p2.fixedId = p.fixedId 
)

і на виконання було потрібно 7,9 секунди.

Нарешті, мій запит:

SELECT  p.id,
    p.fixedId,
    p.azienda_id,
    p.categoria_id,
    p.linea,
    p.tipo,
    p.nome
FROM prodotto p
WHERE p.azienda_id = 2699 AND (p.fixedId, p.anno) IN
(
    SELECT p2.fixedId, MAX(p2.anno)
    FROM prodotto p2
    WHERE p.azienda_id = p2.azienda_id
    GROUP BY p2.fixedId
)

і це зайняло 0,0256 с

Гарний SQL, хороший.

Почніть переглядати плани виконання, щоб побачити відмінності в тому, як сервер SQl інтерпретуватиме їх. Ви також можете використовувати Profiler, щоб реально виконувати запити кілька разів та отримувати різницю.

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

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

Продуктивність ґрунтується на кількості даних, які ви виконуєте на ...

Якщо менше даних, то близько 20 к. ПРИЄДНАЙТЕ краще.

Якщо дані більше схожі на 100k +, то IN працює краще.

Якщо вам не потрібні дані з іншої таблиці, IN - це добре, але краще завжди піти на ІСЦІ.

Усі ці критерії, які я перевірив, і в таблицях мають належні індекси.

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

(Відредаговано для відображення оновленого питання)

Два запити можуть бути не семантично еквівалентними. Якщо працівник працює в більш ніж одному відділі (можливо, на підприємстві, в якому я працюю; правда, це означає, що ваша таблиця не нормалізується повністю), тоді перший запит повертає повторювані рядки, тоді як другий запит не буде. Щоб зробити запити еквівалентними в цьому випадку, DISTINCTдо SELECTпункту повинно бути додано ключове слово , що може вплинути на ефективність.

Зауважте, що існує правило дизайну, яке визначає, що таблиця повинна моделювати сутність / клас або зв'язок між сутностями / класами, але не обидва. Тому я пропоную вам створити третю таблицю, скажімо OrgChart, для моделювання відносин між працівниками та відділами.

Я знаю, що це старий пост, але я вважаю, що це дуже важлива тема, особливо в наші дні, коли ми маємо записи 10M + і говоримо про терабайти даних.

Я також зважуюсь на наступні спостереження. У мене в таблиці близько 45 млн записів ([дані]) і близько 300 записів у таблиці [коти]. У мене є широка індексація для всіх запитів, про які я говорю.

Розглянемо приклад 1:

UPDATE d set category = c.categoryname
FROM [data] d
JOIN [cats] c on c.id = d.catid

порівняно з прикладом 2:

UPDATE d set category = (SELECT TOP(1) c.categoryname FROM [cats] c where c.id = d.catid)
FROM [data] d

Приклад 1 запустив близько 23 хвилин. Приклад 2 займав близько 5 хв.

Тож я б зробив висновок, що підзапит у цьому випадку відбувається набагато швидше. Звичайно, майте на увазі, що я використовую M.2 SSD-накопичувачі, здатні ввімкнути 1 Гб / сек (цей байт не є бітами), тому мої індекси теж дуже швидкі. Тож це може вплинути на швидкість теж у ваших обставинах

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

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

Ви можете використовувати пояснювальний план, щоб отримати об'єктивну відповідь.

Для вашої проблеми фільтр Exists , ймовірно, виконає найшвидше.