Zastosowanie logiki NOT w odniesieniu do indeksów

12

Zgodnie z książką Microsoftu na temat tworzenia baz danych Egzamin 70-433: Tworzenie baz danych Microsoft SQL Server 2008 :

Ani wiodące znaki wieloznaczne, które NIE są logiką, nie pozwalają optymalizatorowi zapytań na użycie indeksów w celu optymalizacji wyszukiwania. Aby uzyskać optymalną wydajność, należy unikać używania słowa kluczowego NOT i wiodących symboli wieloznacznych.

Wziąłem więc, że aby być NOT IN, NOT EXISTSetc

Teraz, jeśli chodzi o to pytanie SO , pomyślałem, że wybrane rozwiązanie @GBN naruszyłoby powyższe stwierdzenie.

Najwyraźniej tak nie jest.

Więc moje pytanie brzmi: dlaczego?

sql-server index optimization

— Stuart Blackler
źródło

21

NOT IN (SELECT ...)i NOT EXISTS (SELECT .. WHERE correlation..)są „Anti Semi Joins”. To znaczy rozpoznane operacje oparte na zestawie
WHERE NOT (MyColumn = 1) to filtr, który wymaga obejrzenia wszystkich wierszy

Aby uzyskać więcej informacji, zobacz:

„Wprowadzenie do połączeń” Craiga Freedmana
Wikipedia „Algebra relacyjna, antyjotyny”

Edycja: dla kompletności

LEFT JOIN często działają gorzej. Zobacz http://explainextended.com/2009/09/15/not-in-vs-not-exists-vs-left-join-is-null-sql-server

Ta sama strona zauważa, że w MySQL NOT EXISTS nie jest zoptymalizowany jak inne RDBMS, a LEFT JOIN jest lepszy

W SQL Server wiem z doświadczenia, że LEFT JOIN nie działa tak dobrze, jak NIE ISTNIEJE. Często potrzebujesz DISTINCT, aby uzyskać te same wyniki, co kolejny etap przetwarzania.

— gbn
źródło

0

Używam do tego podselekcji:

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...));

Oczywiście, jeśli Twój stół jest duży, musisz to przeanalizować, aby sprawdzić wydajność. Jeśli masz dodatkowe klauzule filtrujące wyniki w głównym zapytaniu, być może będziesz musiał je zduplikować w podselekcji. Ale niezależnie od tego, podselekcja ma „IN” w porównaniu z „NOT IN”, a zatem może mieć wyniki o różnej wielkości i, zwykle, ma znaczenie wydajność zapytania, więc przeanalizuj to podejście, gdy używasz z dużą tabelą.

— sofend
źródło