Kryształy filtrowane SQL: czy zawsze powinienem wstawić filtr do indeksu dla kolumn opcjonalnych?

Question

W przypadku "dużych" tabel, czy istnieje jakikolwiek powód, aby nie umieszczać filtru indeksów dla kolumn opcjonalnych?

Tak więc dla indeksu na kolumnie AAA (ponieważ ludzie mogą wyszukiwać w AAA),
Mogę ustawić filtr na ([AAA] IS NOT NULL).
To oszczędza pamięć, więc oszczędza pieniądze.

Niektóre więcej korzyści z technet:

• wydajność i plan Lepsza zapytania jakość
• Niższe koszty utrzymania indeksu
• Niższe koszty składowania indeks

Ludzie mówią, że to jest dobre, aby umieścić filtruj indeks dla kolumn, które są w większości puste. Ale dlaczego nie umieścić filtru na indeksy dla kolumn, które są puste dla 1%? Czy jest jakikolwiek powód, aby tego nie robić, jeśli ma tylko zalety?

Answer 1

Zazwyczaj jest to dobry pomysł z dwóch pułapek:

1. Projektant tabela ma błąd (tylko pre Denali!). Kiedy odbuduje tabelę, usuwa wszystkie filtry.
2. Upewnij się, że optymalizator może stwierdzić statycznie, że Twój predykat nigdy nie pozwoli na zwrócenie pustych wierszy. Zwykle dzieje się tak z powodu SQL NULL semantyki (semmingly jedyny przypadek, w którym pomagają zamiast przeszkadzać). Przykład: select distinct col from T nie użyje indeksu, ponieważ można znaleźć wartość pustą. Użyj tego: select distinct col from T where col is not null.

Indeksy filtrowane są zdecydowanie niedostatecznie wykorzystywane. Mogą nawet zostać użyte do uniknięcia kolumny nullable.

Moje praktyczne zalecenie: po prostu spróbuj przez kilka miesięcy i przekonaj się, czy są dodatkowe nieprzewidziane problemy.

Jeśli korzystasz z zaawansowanych technik zapytań SQL Server, zobacz także widoki indeksowane w reklamie. Są to super zestaw filtrowanych indeksów (przynajmniej na Enterprise).

Answer 2

Wszystkie indeksy mają zalety i wady: Wady:

1. zajmują miejsce na dysku
2. muszą być utrzymywane (saldo drzewo indeks musi być okresowo reorgansised aby zapewnić jakąkolwiek optymalizacja zapytań nie używa dystrybucji danych bum), co może oznaczać, że oznacza, że ​​muszą zostać usunięte - złe wiadomości, jeśli są zajęte
3. potrzebują czasu na aktualizację w locie, jeśli występują częste wstawki

Zalety:

1. Prawidłowo zaprojektowane, mogą wyeliminować drogich skanów tabeli
2. Prawidłowo zaprojektowane, (wskaźnik pokrycia) mogą elimiate dowolną tabelę czytać.

Tak jak zwykle, to zależy.

1. Zbyt wiele indeksów może dramatycznie wolno pisać performanace
2. Zbyt wiele indeksy mogą znacznie zwiększyć wykorzystanie dispace
3. Niewłaściwa indeks może drastycznie zmniejszyć wydajność odczytu

Niektórzy ludzie robią bardzo dobre życie naprawdę znają się na indeksach: Jest tutaj niezmiernie dobra rzecz: http://www.insidesqlserver.com/

Zależy więc od tego, jak często użytkownicy zwracają dane, do których odwołuje się indeks, oraz jak często aktualizują dane zawarte w indeksie.

Indeksy dla kolumn rozrzedzonych nie różnią się, jednak tam, gdzie kolumna jest (w dużej mierze) pusta, przefiltrowane indeksy są bardziej wydajne. Gdy zmniejsza się zapasność (np. 50/50), dystrybucja danych może stać się bardzo ważna, gdy optymalizator wybierze najlepszy plan zwrotu danych.Filtrowany indeks nie będzie znał dystrybucji danych poza filtrem - jest to oczywiste, ale trzeba to powiedzieć.