Продуктивність SQL Server IN проти EXISTS

Мені цікаво, що з наведеного нижче було б більш ефективним?

Я завжди був обережним щодо використання, INтому що я вважаю, що SQL Server перетворює набір результатів у велику IFзаяву. Для великого набору результатів це може призвести до низької ефективності. Що стосується невеликих наборів результатів, я не впевнений, що це є кращим. Чи не EXISTSбуде більш ефективним для великих наборів результатів ?

WHERE EXISTS (SELECT * FROM Base WHERE bx.BoxID = Base.BoxID AND [Rank] = 2)

vs.

WHERE bx.BoxID IN (SELECT BoxID FROM Base WHERE [Rank = 2])

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

З IN, він збиратиме всі результати з підзапиту перед подальшою обробкою.

Прийнята відповідь короткозора, і питання дещо вільне в цьому:

1) Ні явно не згадуйте, чи є індекс покриття в лівій, правій або обох сторонах.

2) Не враховується також розмір набору лівого боку та правого боку введення.
(У питанні просто згадується загальний великий набір результатів ).

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

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

Я провів тестування на SQL Server 2005 та 2008 рр., І на EXISTS, і на IN повернувся з таким самим реальним планом виконання, як і інші. Оптимізатор є оптимальним. :)

Що слід пам’ятати, ІСНУЮЧИЙ, ІНТЕРНЕТ і ПРИЄДНАЙТЕ іноді можуть повертати різні результати, якщо ви не правильно сформулюєте свій запит: http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210 .aspx

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

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

Реляційна (теорія математики) операція, яку ми робимо, коли ми викликаємо, [NOT] INі [NOT] EXISTSє напівз'єднанням (антиз'єднання при використанні NOT). Не випадково відповідні операції sql-сервера мають те саме ім'я . Немає жодної операції, про яку згадується INчи EXISTSдеінде - приєднується лише (анти) напівфабрикат. Таким чином, немає жодного способу, щоб логічно еквівалентний вибір INпроти EXISTSвибору міг вплинути на продуктивність, оскільки існує один і єдиний спосіб операції виконання (анти) напівприєднання, щоб отримати їх результати .

Приклад:

Запит 1 ( план )

select * from dt where dt.customer in (select c.code from customer c where c.active=0)

Запит 2 ( план )

select * from dt where exists (select 1 from customer c where c.code=dt.customer and c.active=0)

Я б поїхав з ІСНУЮЧИМИ над IN, дивіться нижче посилання:

SQL Server: JOIN vs IN vs EXISTS - логічна різниця

Існує поширена помилкова думка, що IN поводиться однаково з EXISTS або ПРИЄДНАЙТЕСЯ з точки зору повернених результатів. Це просто неправда.

IN: Повертає значення true, якщо вказане значення відповідає будь-якому значенню в підзапиті чи списку.

Існує: Повертає істину, якщо підзапит містить будь-які рядки.

Приєднання: приєднується до 2 наборів результатів у стовпчику приєднання.

Кредит блогу: https://stackoverflow.com/users/31345/mladen-prajdic

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

Отже, IN не є тим самим, як EXISTS, і він не буде виробляти той самий план виконання.

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

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

Врахуйте це:

1. Якщо ви використовуєте IN, а внутрішній результат запиту становить мільйони рядків відмінних значень, він, ймовірно, буде виконувати РІШНЕ, ніж ІСНУЮЧИЙ, враховуючи, що запит EXISTS є виконавцем (має правильні індекси для з'єднання із зовнішнім запитом).

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

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

Отже, ВІДПОВІДЬ це ЗАВИСИМО. Ви можете написати складний запит всередині IN чи EXISTS, але, як правило, слід намагатися використовувати IN з обмеженим набором чітких значень та EXISTS, коли у вас багато рядків з великою кількістю чітких значень.

Хитрість полягає в обмеженні кількості рядків для сканування.

З повагою,

MarianoC

Щоб оптимізувати EXISTS, будьте дуже буквальні; щось просто повинно бути там, але насправді вам не потрібні дані, повернені з відповідного підзапиту. Ви просто оцінюєте булеву умову.

Так:

WHERE EXISTS (SELECT TOP 1 1 FROM Base WHERE bx.BoxID = Base.BoxID AND [Rank] = 2)

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

Зверху в голові, і я не гарантую, що буде правильно: я вважаю, що другий буде швидшим у цьому випадку.

1. По-перше, корельований підзапит, ймовірно, призведе до запуску підзапиту для кожного рядка.
2. У другому прикладі підзапит повинен запускатися лише один раз, оскільки не співвіднесений.
3. У другому прикладі INзамикання замикається, як тільки воно знайде відповідність.