Indeksy są dobrym mechanizmem na optymalizację często powtarzających się zapytań. Przykładowo rozważmy następujące zapytanie:
SELECT FirstName,LastName FROM Persons where Age>30
Dla dużej ilości danych, wykonanie powyższego kodu może trochę potrwać. Jeśli dodalibyśmy indeks na kolumnie Age, czas wykonania znaczącą by się skrócił ponieważ dane byłyby w pewnym stopniu sortowane w pamięci (w dużym uproszczeniu dane są przechowywane w strukturze drzewiastej, która znacznie przyśpiesza selekcję).
Tematem postu jednak nie są podstawy indeksów a jego typy. Clusted to podstawowy typ, który jest automatycznie tworzony dla kluczy głównych. Dla tabeli może powstać wyłącznie jeden taki indeks ponieważ stanowi on tak naprawdę fizyczne uporządkowanie danych. Wiersze dodawane do tabeli, domyślnie są zatem sortowanie po kluczu głównym. Każde wywołanie po kluczu indeksu clusted jest zawsze zapytaniem na tzw. covered indeks – indeksie pokrytym. W przypadku powyższego zapytania, o ile indeks został stworzony na kolumnie Age, zapytanie zostanie w pełni zoptymalizowane. W przypadku indeksów non-clusted wszystkie kolumny występujące w zapytaniu (także FirstName, LastName) muszą być dołączone do indeksu w sekcji include – tworzymy więc indeks na Age, z dołączanymi kolumnami FirstName oraz LastName. W przeciwnym przypadku (brak kolumn w include) stworzenie indeksu nie byłoby w stanie w pełni zoptymalizować zapytania.
Liczba indeksów non-clusted jest również ograniczona – maksymalnie 249 chodź to zależy od wersji systemu bazodanowego.
To co warto zrozumieć, to fakt, że indeksy optymalizują wyłącznie operacje selekcji. Ze względu na potrzebę przebudowania drzewa po każdej operacji INSERT, DELETE, UPDATE po dodaniu indeksów są one znacznie wolniejsze.
Z artykułu nie wynika jasno, że indeks clustered należy tworzyć na kolumnie, która jest najczęściej sortowana lub zysk z jej sortowania jest największy.
Zaproponuję jako uzupełnienie, że indeksy przynoszą korzyść głównie w selekcjach, które:
a) zawierają kryteria operujące wyłącznie na polach objętych tym samym indeksem (tzn. istnieje indeks zawierający wszystkie atrybuty wykorzystane w klauzuli where)
b) optymalizator zapytania jest w stanie korzystać z “porządku” indeksu np. podane w artykule porównanie będzie optymalizowane, ale gdybyśmy napisali
“Age*Age > 49” to optymalizator raczej nie wyczai, że ma sprawdzić tylko Age z przedziału [-7; 7], a zrobi skan po całości (oczywiście, gdyby takie zapytania pojawiały się nagminnie, to można rozważać założenie indeks na wyrażenie “Age*Age”)
c) zawierają kryteria wybierające “niewielki” zakres danych w stosunku do całej tabeli (wpp zysk z szybszego wyszukiwania jest mały, a narzut na wstawianie i modyfikacje konkretny).
Oczywiście ostatnia uwaga mocno heurystyczna…