Kolumny INCLUDE

Kolumny INCLUDE to skrótowe określenie pól dołączonych do indeksu w celu pokrycia zapytania bez dostępu do tabeli.

Czym są kolumny INCLUDE w indeksie SQL Server

Kolumny INCLUDE to kolumny niekluczowe zapisane w strukturze indeksu nieklastrowanego programu Microsoft SQL Server. Nie uczestniczą w kluczu indeksu, czyli nie określają kolejności wpisów i nie służą bezpośrednio do wyszukiwania rekordów według operatorów takich jak równość, zakres czy sortowanie. Są natomiast przechowywane razem z wpisem indeksowym jako dodatkowe dane. Dzięki temu indeks może zawierać wartości potrzebne do zwrócenia wyniku zapytania, mimo że te wartości nie są elementem klucza.

Mechanizm ten jest związany z pojęciem indeksu pokrywającego zapytanie. Jeżeli wszystkie kolumny używane przez zapytanie znajdują się w kluczu indeksu albo w jego części INCLUDE, SQL Server może odczytać wynik bez dodatkowego dostępu do tabeli bazowej lub indeksu klastrowanego. Taki dodatkowy odczyt, wykonywany w celu pobrania brakujących kolumn, jest często widoczny w planie wykonania jako Key Lookup albo RID Lookup. Kolumny INCLUDE mogą ograniczyć liczbę takich operacji, ale nie zmieniają zasad wyszukiwania określanych przez klucz indeksu.

Różnica między kluczem indeksu a częścią INCLUDE

Kolumny kluczowe indeksu mają znaczenie dla organizacji danych w strukturze B-tree. SQL Server może wykorzystać je do znalezienia zakresu wpisów odpowiadającego predykatowi WHERE, do realizacji sortowania wyników albo do wykonania operacji złączenia. Kolejność kolumn kluczowych ma znaczenie, ponieważ indeks jest uporządkowany przede wszystkim według pierwszej kolumny klucza, następnie według kolejnych kolumn.

Kolumny INCLUDE nie są uporządkowane w taki sposób, aby można było efektywnie wyszukiwać po ich wartości. Jeżeli zapytanie filtruje dane wyłącznie po kolumnie umieszczonej w INCLUDE, obecność tej kolumny nie zapewnia typowego seeka po tej wartości. Kolumna może jednak umożliwić odczytanie wyniku bez lookupu, gdy główne kryterium wyszukiwania korzysta z kolumn kluczowych. Przykładowo indeks z kluczem CustomerID i kolumną INCLUDE OrderDate może pokryć zapytanie filtrujące po CustomerID i zwracające OrderDate, ale sama kolumna OrderDate nie staje się przez to kluczem wyszukiwania.

Wpływ na plan wykonania i koszty indeksu

Projektując indeks z kolumnami INCLUDE, należy porównać koszt dodatkowego miejsca oraz utrzymania indeksu z kosztem lookupów wykonywanych przez zapytanie. Indeks nieklastrowany jest aktualizowany podczas operacji INSERT, DELETE oraz zmian wartości objętych indeksem. Jeżeli aktualizowana jest kolumna znajdująca się w INCLUDE, jej nowa wartość również musi zostać zapisana w odpowiednim wpisie indeksowym. Rozbudowany indeks może więc zwiększać rozmiar bazy, zużycie pamięci podręcznej i koszt modyfikacji danych.

Kolumny dołączane powinny być wybierane na podstawie rzeczywistych zapytań i ich planów wykonania. Warto sprawdzić, czy problemem jest duża liczba lookupów, czy może niewłaściwy predykat, brak odpowiedniego klucza, nieaktualne statystyki albo selektywność filtra. Samo dodanie wielu kolumn do INCLUDE nie gwarantuje poprawy. Szeroki indeks może prowadzić do większych odczytów stron i zwiększać obciążenie podczas przebudowy lub reorganizacji indeksów. Należy również uważać na kolumny o dużych typach danych, ponieważ SQL Server nakłada ograniczenia dotyczące typów, które mogą występować jako kolumny dołączone.

Praktyczne sprawdzanie indeksu pokrywającego zapytanie

Analizę należy rozpocząć od konkretnego zapytania oraz jego rzeczywistego planu wykonania. W planie trzeba zweryfikować operator dostępu do danych, liczbę wykonywanych lookupów, szacowaną i rzeczywistą liczbę wierszy oraz koszt odczytu. Jeżeli zapytanie wyszukuje po kolumnie kluczowej, ale pobiera dodatkowe pola z tabeli, indeks z właściwie dobranymi kolumnami INCLUDE może usunąć operator Key Lookup. Nie oznacza to jednak, że każdy lookup jest błędem. Przy małej liczbie zwracanych wierszy jego koszt może być niższy niż koszt utrzymywania szerokiego indeksu.

Podczas diagnostyki warto także sprawdzić definicję indeksu w katalogach systemowych SQL Server, jego rozmiar, fragmentację oraz częstotliwość użycia. Istotne jest rozróżnienie kolumn używanych do filtrowania i łączenia od kolumn potrzebnych wyłącznie w klauzuli SELECT. Te pierwsze zwykle powinny być rozważane jako kolumny kluczowe, natomiast te drugie mogą być kandydatami do INCLUDE. Ostateczna ocena wymaga porównania planów przed i po zmianie oraz obserwacji zachowania zapytań przy reprezentatywnej liczbie danych.