NOT in vs NOT EXISTS

Należy również pamiętać, że NOT IN nie jest równoznaczne z NOT EXISTS jeśli chodzi o null.

Ten post wyjaśnia to bardzo dobrze

Http://sqlinthewild.co.za/index.php/2010/02/18/not-exists-vs-not-in/

Gdy zapytanie podrzędne zwróci nawet jedno null, NOT IN nie będzie pasować do żadnego rzędy.

Przyczyny tego można znaleźć, patrząc na szczegóły tego, co Nie działa właściwie oznacza.

Powiedzmy, dla celów ilustracyjnych, że są 4 rzędy w w tabeli o nazwie t znajduje się kolumna o nazwie ID o wartości 1..4

WHERE SomeValue NOT IN (SELECT AVal FROM t)

Jest równoważne

WHERE SomeValue != (SELECT AVal FROM t WHERE ID=1)
AND SomeValue != (SELECT AVal FROM t WHERE ID=2)
AND SomeValue != (SELECT AVal FROM t WHERE ID=3)
AND SomeValue != (SELECT AVal FROM t WHERE ID=4)

Powiedzmy, że AVal jest NULL, gdzie ID = 4. Stąd != porównanie zwraca nieznany. Tabela prawdy logicznej dla i stanowi to nieznane i prawdziwe jest nieznane, nieznane i fałszywe jest fałszywe. Jest nie ma wartości, która może być I ' d z UNKNOWN, aby uzyskać wynik TRUE

Stąd, Jeśli jakikolwiek wiersz tego zapytania podrzędnego zwróci NULL, Cała NIE W operator będzie oceniał na FALSE lub NULL i żadne rekordy nie będą Return

Jeśli planer egzekucji mówi, że są takie same, to są takie same. Użyj tego, który sprawi, że Twój zamiar będzie bardziej oczywisty-w tym przypadku, drugi.

Faktycznie, to chyba najszybsze:

SELECT ProductID, ProductName 
    FROM Northwind..Products p  
          outer join Northwind..[Order Details] od on p.ProductId = od.ProductId)
WHERE od.ProductId is null

Mam tabelę, która ma około 120 000 rekordów i muszę wybrać tylko te, które nie istnieją (dopasowane do kolumny varchar) w czterech innych tabelach z liczbą wierszy około 1500, 4000, 40000, 200. Wszystkie tabele mają unikalny indeks w danej kolumnie Varchar.

NOT IN zajęło około 10 minut, NOT EXISTS zajęło 4 sekundy.

Mam rekursywne zapytanie, które może mieć jakiś untuned sekcja, która może przyczynić się do 10 min, ale druga opcja zajmuje 4 sek wyjaśnia, przynajmniej dla mnie, że NOT EXISTS jest o wiele lepszy, a przynajmniej to, że IN i EXISTS nie są dokładnie takie same i zawsze warto sprawdzić, zanim przejdziesz do przodu z kodem.

W twoim konkretnym przykładzie są one takie same, ponieważ optymalizator zorientował się, że to, co próbujesz zrobić, jest takie samo w obu przykładach. Ale jest możliwe, że w nietrywialnych przykładach optymalizator może tego nie robić, a w takim przypadku istnieją powody, aby czasami preferować jeden od drugiego.

NOT IN powinno być preferowane, jeśli testujesz wiele wierszy w zewnętrznym select. Zapytanie podrzędne wewnątrz NOT IN może być oceniane na początku wykonania, a tymczasowe tabela może być sprawdzana pod kątem każdej wartości w zewnętrznym select, zamiast każdorazowo ponownie uruchamiać zaznaczenie podrzędne, tak jak byłoby to wymagane za pomocą instrukcji NOT EXISTS.

Jeśli zapytanie podrzędne musi być skorelowane z zewnętrznym select, to NOT EXISTS może być preferowane, ponieważ optymalizator może odkryć uproszczenie, które uniemożliwia tworzenie tymczasowych tabel do wykonywania tej samej funkcji.

Używałem

SELECT * from TABLE1 WHERE Col1 NOT IN (SELECT Col1 FROM TABLE2)

I okazało się, że daje złe wyniki(przez złe mam na myśli żadnych wyników). Jak było NULL w tabeli 2./ Colspan = 1 /

Podczas Zmiany zapytania na

SELECT * from TABLE1 T1 WHERE NOT EXISTS (SELECT Col1 FROM TABLE2 T2 WHERE T1.Col1 = T2.Col2)

Dał mi prawidłowe wyniki.

Od tego czasu zacząłem używać NOT EXISTS every where.

Są bardzo podobne, ale nie do końca takie same.

Jeśli chodzi o wydajność, odkryłem, że Left join jest null twierdzenie bardziej efektywne (gdy ma być zaznaczona liczba wierszy, czyli)

Jeśli optymalizator mówi, że są takie same, rozważ czynnik ludzki. Wolę zobaczyć, że nie istnieje:)

To zależy..

SELECT x.col
FROM big_table x
WHERE x.key IN( SELECT key FROM really_big_table );

Nie byłoby stosunkowo powolne, nie ma zbyt wiele, aby ograniczyć rozmiar tego, co sprawdza zapytanie, aby sprawdzić, czy klucz jest w. Istnieje byłoby korzystne w tym przypadku.

Ale, w zależności od optymalizatora DBMS, nie może być inaczej.

Jako przykład kiedy istnieje jest lepiej

SELECT x.col
FROM big_table x
WHERE EXISTS( SELECT key FROM really_big_table WHERE key = x.key);
  AND id = very_limiting_criteria