NULL złożoności – część 1

Plan dla zapytania 1 pokazano na rysunku 1.

Rysunek 1:Plan dla zapytania 1

Tabela zawiera indeks pokrywający, który obsługuje to zapytanie. Indeks nazywa się idx_nc_shippeddate i jest zdefiniowany za pomocą listy kluczy (shippeddate, orderid). Predykat filtra zapytania jest wyrażony jako argument wyszukiwania (SARG) , co oznacza, że ​​umożliwia optymalizatorowi rozważenie zastosowania operacji wyszukiwania w indeksie pomocniczym, przechodząc bezpośrednio do zakresu kwalifikujących się wierszy. To, co sprawia, że ​​predykat filtru SARG jest możliwy do zrealizowania, polega na tym, że używa operatora, który reprezentuje kolejny zakres kwalifikujących się wierszy w indeksie, i że nie stosuje manipulacji do filtrowanej kolumny. Otrzymany plan jest optymalnym planem dla tego zapytania.

Ale co, jeśli chcesz, aby użytkownicy mogli prosić o niewysłane zamówienia? Takie zamówienia mają NULL datę wysyłki. Oto próba przekazania NULL jako daty wejściowej:

DECLARE @dt AS DATE =NULL; SELECT identyfikator zamówienia, data wysyłkiFROM Sprzedaż.ZamówieniaWHERE data wysyłki =@dt;

Jak już wiesz, predykat używający operatora równości tworzy UNKNOWN, gdy którykolwiek z operandów ma wartość NULL. W konsekwencji to zapytanie zwraca pusty wynik:

identyfikator zamówienia data wysyłki----------- -----------(0 wierszy dotyczy)

Mimo że T-SQL obsługuje operator IS NULL, nie obsługuje jawnego operatora IS . Nie możesz więc użyć predykatu filtrującego, takiego jak WHERE senddate IS @dt. Ponownie opowiem o nieobsługiwanej standardowej alternatywie w przyszłym artykule. To, co wiele osób robi, aby rozwiązać tę potrzebę w T-SQL, to użycie funkcji ISNULL lub COALESCE do zastąpienia wartości NULL wartością, która normalnie nie może pojawić się w danych po obu stronach, tak jak to (nazwę to zapytanie 2):

DECLARE @dt AS DATE =NULL; SELECT identyfikator zamówienia, senddateFROM Sales.OrdersWHERE ISNULL(shippeddate, '99991231') =ISNULL(@dt, '99991231');

To zapytanie generuje poprawne dane wyjściowe:

identyfikator zamówienia data wysyłki----------- -----------11008 NULL11019 NULL11039 NULL...11075 NULL11076 NULL11077 NULL (dotyczy 21 wierszy)

Ale plan dla tego zapytania, jak pokazano na rysunku 2, nie jest optymalny.

Rysunek 2:Plan dla zapytania 2

Ponieważ zastosowano manipulację do filtrowanej kolumny, predykat filtru nie jest już uważany za SARG. Indeks nadal obejmuje, więc można go używać; ale zamiast stosowania wyszukiwania w indeksie przechodzącego bezpośrednio do zakresu kwalifikujących się wierszy, skanowany jest cały liść indeksu. Załóżmy, że tabela zawiera 50 000 000 zamówień, a tylko 1000 to zamówienia niewysłane. Ten plan skanowałby wszystkie 50 000 000 wierszy zamiast wyszukiwania, które przechodzi bezpośrednio do kwalifikującego się 1000 wierszy.

Jedną z form predykatu filtru, w której oba mają poprawne znaczenie, którego szukamy i która jest uważana za argument wyszukiwania, jest (datawysyłki =@dt LUB (datawysyłki JEST NULL I @dt JEST NULL)). Oto zapytanie używające predykatu SARGable (nazwiemy je Zapytanie 3):

DECLARE @dt AS DATE =NULL; SELECT identyfikator zamówienia, senddateFROM Sales.OrdersWHERE (data wysyłki =@dt OR (data wysyłki JEST NULL ORAZ @dt JEST NULL));

Plan dla tego zapytania pokazano na rysunku 3.

Rysunek 3:Plan dla zapytania 3

Jak widać, plan stosuje wyszukiwanie w indeksie pomocniczym. Predykat seek mówi senddate =@dt, ale jest wewnętrznie zaprojektowany do obsługi wartości NULL, tak jak wartości inne niż NULL, ze względu na porównanie.

To rozwiązanie jest powszechnie uważane za rozsądne. Jest standardowy, optymalny i poprawny. Jego główną wadą jest to, że jest gadatliwy. Co by było, gdybyś miał wiele predykatów filtrujących opartych na kolumnach dopuszczających NULL? Szybko otrzymasz długą i kłopotliwą klauzulę WHERE. A jest znacznie gorzej, gdy trzeba napisać predykat filtrujący obejmujący kolumnę dopuszczalną NULL, która szuka wierszy, w których kolumna jest inna niż parametr wejściowy. Predykat staje się wtedy:(shippeddate <> @dt AND ((shippeddate JEST NULL ORAZ @dt IS NOT NULL) LUB (shippeddate JEST NULL i @dt JEST NULL))).

Widać wyraźnie potrzebę bardziej eleganckiego rozwiązania, które byłoby jednocześnie zwięzłe i optymalne. Niestety niektórzy uciekają się do niestandardowego rozwiązania, w którym wyłącza się opcję sesji ANSI_NULLS. Ta opcja powoduje, że SQL Server używa niestandardowej obsługi równości (=) i operatorów różnych niż (<>) z logiką dwuwartościową zamiast trójwartościowej, traktując wartości NULL tak samo jak wartości inne niż NULL do celów porównawczych. Tak jest przynajmniej, o ile jeden z operandów jest parametrem/zmienną lub literałem.

Uruchom następujący kod, aby wyłączyć opcję ANSI_NULLS w sesji:

WYŁĄCZ ANSI_NULLS;

Uruchom następujące zapytanie, używając prostego predykatu opartego na równości:

DECLARE @dt AS DATE =NULL; SELECT identyfikator zamówienia, data wysyłkiFROM Sprzedaż.ZamówieniaWHERE data wysyłki =@dt;

To zapytanie zwraca 21 niewysłanych zamówień. Otrzymujesz ten sam plan, który pokazano wcześniej na rysunku 3, pokazując wyszukiwanie w indeksie.

Uruchom następujący kod, aby przełączyć się z powrotem do standardowego zachowania, gdy ANSI_NULLS jest włączone:

WŁĄCZ ANSI_NULLS;

Zdecydowanie odradza się poleganie na takim niestandardowym zachowaniu. Dokumentacja stwierdza również, że obsługa tej opcji zostanie usunięta w niektórych przyszłych wersjach programu SQL Server. Co więcej, wielu nie zdaje sobie sprawy, że ta opcja ma zastosowanie tylko wtedy, gdy przynajmniej jeden z operandów jest parametrem/zmienną lub stałą, mimo że dokumentacja jest na ten temat dość jasna. Nie ma to zastosowania przy porównywaniu dwóch kolumn, na przykład w łączeniu.

Jak więc poradzić sobie ze złączeniami obejmującymi kolumny złączeń dopuszczające NULL, jeśli chcesz uzyskać dopasowanie, gdy obie strony mają wartości NULL? Jako przykład użyj następującego kodu, aby utworzyć i wypełnić tabele T1 i T2:

DROP TABLE IF EXISTS dbo.T1, dbo.T2;GO CREATE TABLE dbo.T1(k1 INT NULL, k2 INT NULL, k3 INT NULL, val1 VARCHAR(10) NOT NULL, CONSTRAINT UNQ_T1 UNIQUE CLUSTERED(k1, k2 , k3)); CREATE TABLE dbo.T2(k1 INT NULL, k2 INT NULL, k3 INT NULL, val2 VARCHAR(10) NOT NULL, CONSTRAINT UNQ_T2 UNIQUE CLUSTERED(k1, k2, k3)); INSERT INTO dbo.T1(k1, k2, k3, val1) WARTOŚCI (1, NULL, 0, 'A'),(NULL, NULL, 1, 'B'),(0, NULL, NULL, 'C') ,(1, 1, 0, 'D'),(0, NULL, 1, 'F'); WSTAW W dbo.T2(k1, k2, k3, val2) WARTOŚCI (0, 0, 0, 'G'),(1, 1, 1, 'H'),(0, NULL, NULL, 'I') ,(NULL, NULL, NULL, 'J'),(0, NULL, 1, 'K');

Kod tworzy indeksy pokrywające w obu tabelach, aby obsługiwać łączenie oparte na kluczach łączenia (k1, k2, k3) po obu stronach.

Użyj poniższego kodu, aby zaktualizować statystyki kardynalności, zwiększając liczby tak, aby optymalizator pomyślał, że masz do czynienia z większymi tabelami:

ZAKTUALIZUJ STATYSTYKI dbo.T1(UNQ_T1) Z ROWCOUNT =1000000; AKTUALIZUJ STATYSTYKI dbo.T2(UNQ_T2) Z ROWCOUNT =1000000;

Użyj następującego kodu, aby połączyć dwie tabele za pomocą prostych predykatów opartych na równości:

WYBIERZ T1.k1, T1.K2, T1.K3, T1.val1, T2.val2FROM dbo.T1 SPRZECZENIE WEWNĘTRZNE dbo.T2 ON T1.k1 =T2.k1 AND T1.k2 =T2.k2 AND T1. k3 =T2.k3;

Podobnie jak we wcześniejszych przykładach filtrowania, również tutaj porównania między wartościami NULL przy użyciu operatora równości dają UNKNOWN, co skutkuje niedopasowaniami. To zapytanie generuje puste dane wyjściowe:

k1 K2 K3 val1 val2----------- ----------- ----------- --------- - ----------(0 wpływa na wiersze)

Użycie ISNULL lub COALESCE, tak jak we wcześniejszym przykładzie filtrowania, zastąpienie wartości NULL wartością, która normalnie nie może pojawić się w danych po obu stronach, daje w wyniku poprawne zapytanie (nazywam to zapytanie zapytaniem 4):

 SELECT T1.k1, T1.K2, T1.K3, T1.val1, T2.val2FROM dbo.T1 INNER JOIN dbo.T2 ON ISNULL(T1.k1, -2147483648) =ISNULL(T2.k1, -2147483648 ) AND ISNULL(T1.k2, -2147483648) =ISNULL(T2.k2, -2147483648) AND ISNULL(T1.k3, -2147483648) =ISNULL(T2.k3, -2147483648);

To zapytanie generuje następujące dane wyjściowe:

k1 K2 K3 val1 val2----------- ----------- ----------- --------- - ----------0 NULL NULL C I0 NULL 1 F K

Jednak podobnie jak manipulowanie filtrowaną kolumną łamie zdolność SARG predykatu filtra, manipulowanie kolumną sprzężenia uniemożliwia poleganie na kolejności indeksu. Można to zobaczyć w planie dla tego zapytania, jak pokazano na rysunku 4.

Rysunek 4:Plan dla zapytania 4

Optymalny plan dla tego zapytania to taki, który stosuje uporządkowane skany dwóch indeksów obejmujących, po których następuje algorytm Merge Join, bez jawnego sortowania. Optymalizator wybrał inny plan, ponieważ nie mógł polegać na kolejności indeksowania. Jeśli spróbujesz wymusić algorytm Merge Join przy użyciu INNER MERGE JOIN, plan nadal będzie polegał na nieuporządkowanych skanach indeksów, po których nastąpi jawne sortowanie. Spróbuj!

Oczywiście możesz użyć długich predykatów podobnych do predykatów SARGable pokazanych wcześniej do zadań filtrowania:

WYBIERZ T1.k1, T1.K2, T1.K3, T1.val1, T2.val2FROM dbo.T1 SPRZECZENIE WEWNĘTRZNE dbo.T2 ON (T1.k1 =T2.k1 LUB (T1.k1 JEST NULL AND T2) K1 JEST NULL)) AND (T1.k2 =T2.k2 LUB (T1.k2 JEST NULL I T2.K2 JEST NULL)) AND (T1.k3 =T2.k3 OR (T1.k3 JEST NULL I T2.K3 JEST NULL)) NULL));

To zapytanie daje pożądany wynik i umożliwia optymalizatorowi poleganie na kolejności indeksów. Jednak naszą nadzieją jest znalezienie rozwiązania, które będzie zarówno optymalne, jak i zwięzłe.

Istnieje mało znana, elegancka i zwięzła technika, której można używać zarówno w sprzężeniach, jak i filtrach, zarówno w celu identyfikacji dopasowań, jak i identyfikacji niedopasowań. Ta technika została odkryta i udokumentowana już wiele lat temu, tak jak we wspaniałym artykule Paula White'a Plany nieudokumentowanych zapytań:Porównania równości z 2011 roku. Ale z jakiegoś powodu wydaje się, że wiele osób wciąż o tym nie wie i niestety kończą używanie nieoptymalnych, długich i niestandardowe rozwiązania. Z pewnością zasługuje na większą ekspozycję i miłość.

Technika ta opiera się na fakcie, że operatory zbiorów, takie jak INTERSECT i EXCEPT, używają podejścia opartego na odrębności podczas porównywania wartości, a nie podejścia opartego na równości lub nierówności.

Rozważ nasze wspólne zadanie jako przykład. Gdybyśmy nie musieli zwracać kolumn innych niż klucze złączenia, użylibyśmy prostego zapytania (nazwę go Query 5) z operatorem INTERSECT, na przykład:

SELECT k1, k2, k3 FROM dbo.T1INTERSECTSELECT k1, k2, k3 FROM dbo.T2;

To zapytanie generuje następujące dane wyjściowe:

k1 k2 k3----------- ----------- -----------0 NULL NULL0 NULL 1

Plan dla tego zapytania pokazano na rysunku 5, który potwierdza, że ​​optymalizator mógł polegać na kolejności indeksów i używać algorytmu łączenia łączenia.

Rysunek 5:Plan dla zapytania 5

Jak zauważa Paul w swoim artykule, plan XML dla operatora zbioru używa niejawnego operatora porównania IS (CompareOp="IS" ) w przeciwieństwie do operatora porównania EQ używanego w normalnym złączeniu (CompareOp="EQ" ). Problem z rozwiązaniem, które opiera się wyłącznie na operatorze zbioru, polega na tym, że ogranicza ono do zwracania tylko kolumn, które porównujesz. To, czego naprawdę potrzebujemy, to rodzaj hybrydy między złączeniem a operatorem mnogościowym, pozwalającej na porównywanie podzbioru elementów przy jednoczesnym zwróceniu dodatkowych elementów, tak jak robi to złącze, i używając porównania opartego na odrębności (IS), tak jak robi to operator mnogościowy. Jest to osiągalne przez użycie sprzężenia jako konstrukcji zewnętrznej i predykatu EXISTS w klauzuli ON sprzężenia opartego na zapytaniu z operatorem INTERSECT porównującym klucze sprzężenia z dwóch stron, tak jak to (będę nazywał to Query 6):

WYBIERZ T1.k1, T1.K2, T1.K3, T1.val1, T2.val2FROM dbo.T1 INNER JOIN dbo.T2 ON EXISTS(WYBIERZ T1.k1, T1.k2, T1.k3 PRZECIĘCIE WYBIERZ T2. k1, T2.k2, T2.k3);

Operator INTERSECT operuje na dwóch zapytaniach, z których każde tworzy zestaw jednego wiersza na podstawie kluczy sprzężenia z obu stron. Gdy dwa wiersze są takie same, zapytanie INTERSECT zwraca jeden wiersz; predykat EXISTS zwraca TRUE, co skutkuje dopasowaniem. Gdy te dwa wiersze nie są takie same, zapytanie INTERSECT zwraca pusty zestaw; predykat EXISTS zwraca FALSE, co skutkuje niedopasowaniem.

To rozwiązanie generuje pożądany wynik:

k1 K2 K3 val1 val2----------- ----------- ----------- --------- - ----------0 NULL NULL C I0 NULL 1 F K

Plan dla tego zapytania pokazano na rysunku 6, potwierdzając, że optymalizator mógł polegać na kolejności indeksów.

Rysunek 6:Plan dla zapytania 6

Możesz użyć podobnej konstrukcji jako predykatu filtra obejmującego kolumnę i parametr/zmienną do wyszukiwania dopasowań na podstawie odrębności, na przykład:

DECLARE @dt AS DATE =NULL; SELECT identyfikator zamówienia, data wysyłkiFROM Sales.OrdersWHERE EXISTS (SELECT data wysyłki INTERSECT SELECT @dt);

Plan jest taki sam, jak ten pokazany wcześniej na rysunku 3.

Możesz także zanegować predykat, aby wyszukać niedopasowania, na przykład:

DECLARE @dt JAKO DATA ='20190212'; SELECT identyfikator zamówienia, data wysyłkiFROM Sales.OrdersWHERE NOT EXISTS (SELECT data wysyłki INTERSECT SELECT @dt);

To zapytanie generuje następujące dane wyjściowe:

DECLARE @dt JAKO DATA ='20190212'; SELECT identyfikator zamówienia, data wysyłkiFROM Sales.OrdersWHERE EXISTS (SELECT data wysyłki EXCEPT SELECT @dt);