Zauważyłem, że bardzo niewiele osób rozumie, jak działają indeksy w SQL Server, zwłaszcza w kolumnach dołączonych. Niemniej jednak indeksy to świetny sposób na optymalizację zapytań. Na początku również nie miałem pojęcia o dołączonych kolumnach, ale moje eksperymenty wykazały, że są one bardzo przydatne.
Załóżmy, że mamy następującą tabelę i zapytanie:
CREATE TABLE Person ( PersonID int, FirstName varchar(100), LastName varchar(100), Age int, … … ) SELECT FirstName, LastName, Age FROM Person WHERE FirstName = 'John' and LastName = 'Smith'
Oczywiste jest, że PersonID jest kluczem podstawowym. Załóżmy, że mamy indeks według imienia i nazwiska, nazwijmy go IX_Person_FirstNameLastName. Plan wykonania takiego zapytania będzie wyglądał następująco:
- Zlokalizowanie wszystkich wierszy z określonymi imionami i nazwiskami za pomocą drzewa indeksów IX_Person_FirstNameLastName
- Wykrywanie rzeczywistej lokalizacji linii na dysku na liściach indeksu, przejście do rzeczywistej lokalizacji i odczytywanie wieku.
Załóżmy teraz, że to zapytanie jest wykonywane dość często. Za każdym razem musimy wykonać 2 kroki. Czy można to zoptymalizować? W przypadku MS SQL Server nie stanowi to problemu – możesz wpisać wartości bezpośrednio do indeksu za pomocą opcji INCLUDE.
CREATE INDEX IX_PERSON ON Person ( FirstName, LastName ) INCLUDE(Age)
Teraz to pole nie jest używane podczas indeksowania, ale jest uwzględnione w indeksie. Jakie problemy możemy napotkać w tym zakresie? Kiedy indeksujemy tabelę według pewnego pola, serwer bazy danych musi zbudować drzewo indeksów według tego pola. Oznacza to, że przy zmianie wartości musimy zmienić drzewo indeksu. Kiedy wartości są intensywnie modyfikowane, staje się to problematycznym i trudnym zadaniem dla serwera. Kiedy aktualizacja staje się zbyt duża, czasami łatwiej jest upuścić indeks. Indeks znacznie optymalizuje wyszukiwanie, ale negatywnie wpływa na operacje wstawiania, usuwania i aktualizacji.
Jeśli pole jest po prostu zawarte w indeksie, nie jest używane podczas budowania drzewa indeksu i nie ma na nie wpływu, ale wartość można łatwo znaleźć na liściu tego drzewa. Gdy następuje wyszukiwanie po nazwisku i imieniu, serwer wyszukuje wszystkie imiona i nazwiska z drzewa, a gdy dotrze do liścia (znajdzie wymaganą wartość indeksu), to oprócz wskaźnika do fizycznej lokalizacji wartości wiersza, zawiera również wartości pól zawarte w indeksie. Oznacza to, że nie ma potrzeby robienia drugiego kroku, aby przejść do fizycznej lokalizacji linii i odczytać ją stamtąd.
Ponieważ nie musisz zmieniać drzewa podczas modyfikowania danych o wieku, wszystkie te rzeczy nie wpływają zbytnio na operacje modyfikacji danych. Nie musimy zmieniać indeksu, wystarczy zmienić wartości na liściu drzewa. Dlatego nawet ogromna zmiana pola Age nie będzie miała dużego wpływu na wydajność. Z pewnością wpłynie to, ale nie tak bardzo.
O ile mi wiadomo, wartości indeksu klastrowego są automatycznie uwzględniane na poziomie liścia, ale należy to sprawdzić ze specyfikacją.
Kiedy więc korzystanie z dołączonych pól jest korzystne? Gdy są często używane w wynikach zapytań, ale są zmieniane raz na jakiś czas. Przykładem jest tabela transakcji bankowych. Tabela taka może składać się z następujących pól:numer rachunku, typ transakcji, data, suma. Indeksowanie według sumy nie ma sensu, ale możemy uwzględnić ją w indeksie i znacznie przyspieszy to zapytanie.
Aby uzyskać rzeczywisty efekt z indeksowania, zapytania nie powinny zaznaczać wszystkich pól, czyli należy zapomnieć o tabeli SELECT * FROM. Zawsze przeliczaj tylko te pola, których naprawdę potrzebujesz. A jeśli ich wartości znajdą się w indeksie, szybkość wykonania może być dość wysoka.
Przydatne narzędzie:
dbForge Index Manager – poręczny dodatek SSMS do analizy stanu indeksów SQL i rozwiązywania problemów z fragmentacją indeksów.
