Uwzględniona kolumna a filtrowany indeks

Obecnie pracujemy z tabelą o nazwie tb_tranfers . Ta tabela ma 40 milionów wierszy i ma rozmiar ~ 26 GB (dane 11 GB, indeksy 15 GB).

10 do 15% wierszy to wiersze z miękkim usunięciem (Data Usunięcia nie jest pusta). W aplikacji użyto tylko wierszy, w których usunięto datę zerową. Wszystkie zapytania do tej tabeli będą zawierać klauzulę na ten temat.

Tabela zawiera 15 indeksów. Brakujący indeks DMV zawiera sugestie dotyczące tworzenia indeksów z usuniętą datą jako zawartą kolumną.

Czy użyteczne byłoby użycie filtrowanego indeksu WHERE DeleteDdate IS NULLwe wszystkich 11 indeksach nieuporządkowanych? Czy może lepiej byłoby mieć kolumnę DeleteDate jako kolumnę dołączoną?

Tak, CREATE INDEX ... ON ... WHERE DeletedDate IS NULLpomogłoby zmodyfikowanie wszystkich 11 indeksów NC do filtrowania indeksy ( ). W ten sposób zyskujesz dwie zalety:

• Query Optimizer będą wiedzieć, że każdy rząd pochodzący z tych indeksów już nie spełniać swoje filtry zapytań na DeletedDate, więc nie będzie musiał odnośnika do indeksu klastrowego dokładnie sprawdzić DeletedDate
• Wszystkie indeksy NC będą o 10-15% mniejsze, co wymaga mniej pamięci i mniej operacji IO do wyszukiwania.

Kompromis polega na tym, że każde zapytanie, które opiekuje się miękko usuniętymi wierszami (i musi być jakieś zapytanie, w przeciwnym razie dlaczego wiersze istnieją?) Nie będzie mogło korzystać z tych indeksów NC.

Jeśli ZAWSZE korzystasz z DeletedDate IS NULLfiltra w swoich zapytaniach, to tak, prawdopodobnie zauważysz znaczny wzrost wydajności poprzez dodanie filtra.

Jest o wiele mniej stron do sprawdzenia przez silnik w celu znalezienia odpowiednich wierszy, co oznacza mniej IO (i większą prędkość).

Dodanie go jako INCLUDEDpola byłoby bezużyteczne . Ponieważ zawsze umieszczasz go w filtrze (ale prawdopodobnie nigdy nie dodajesz go do listy WYBIERZ), to pole nigdy nie będzie przywoływane, jeśli dodasz je jako INCLUDE.

Ponieważ 85–90% wierszy ma wartość RemoveDate ma wartość NULL, jest mało prawdopodobne, aby selektywność indeksu składającego się wyłącznie z parametru DeleteDate była wystarczająca, aby SQL mógł użyć tego indeksu. Jednak użycie w połączeniu z innymi bardziej selektywnymi kolumnami, dodanie opcji DeleteDate do istniejących indeksów powinno przynieść pewne korzyści, jeśli zwiększy ogólną selektywność indeksu.

Jak mówi JNK, funkcja DeleteDate byłaby mało przydatna w pokrywaniu indeksów, chyba że użyjesz jej w klauzuli SELECT.

Biorąc pod uwagę, że jest już więcej miejsca na indeksy niż na dane, możesz również sprawdzić, czy istnieje jakaś nadmiarowość w istniejących 15 indeksach NC.