Використання логіки NOT стосовно індексів

Відповідно до книги Microsoft щодо розробки бази даних Іспит 70-433: Розробка бази даних Microsoft SQL Server 2008 :

Жоден із провідних символів підстановки, що НЕ логічно, дозволяє оптимізатору запитів використовувати індекси для оптимізації пошуку. Для оптимальної продуктивності слід уникати використання ключового слова NOT та провідних символів.

Так що я взяв , що бути NOT IN, і NOT EXISTSт.д.

Тепер щодо цього SO питання, я подумав , що обране рішення по @GBN порушило б заяву , дане вище.

Мабуть, це не так.

Отже, моє запитання: чому?

• NOT IN (SELECT ...)і NOT EXISTS (SELECT .. WHERE correlation..)є "Анти-Полу Приєднання". Тобто, визнані операції на основі множин

• WHERE NOT (MyColumn = 1) це фільтр, який вимагає перегляду всіх рядків

Для отримання додаткової інформації див:

• Кріг Фрідман "Вступ до об'єднань"
• Вікіпедія "Реляційна алгебра, протиз'єднання"

Редагувати: для повноти

ЛІВНІ ПРИЄДНАННЯ часто працюють гірше. Дивіться http://explainextended.com/2009/09/15/not-in-vs-not-exists-vs-left-join-is-null-sql-server

Цей же сайт зазначає, що в MySQL НЕ ІСНУЄТЬСЯ не оптимізовано, як і інші RDBMS, а лівий СПОЛУЧЕННЯ краще

У SQL Server я з досвіду знаю, що НЕ ПРИЄДНАЄТЬСЯ, а НЕ ІСНУЄ. Також вам часто потрібно DISTINCT, щоб отримати ті самі результати, що й інший етап обробки.

Для цього я використовую підбір:

SELECT m* from Main AS m 
    WHERE m.id NOT IN 
        (SELECT m2.id FROM Main AS m2 
           WHERE m2.id IN (...possibly null/empty list goes here...));

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