sys.indexes zwraca listę wszystkich indeksów zdefiniowanych w bazie wraz z ich typem i właściwościami.
Rola widoku sys.indexes w SQL Server
sys.indexes jest katalogowym widokiem systemowym aparatu Microsoft SQL Server. Zwraca jeden wiersz dla każdego indeksu zdefiniowanego dla obiektu tabeli lub widoku w bieżącej bazie danych. Widok należy odczytywać w kontekście konkretnej bazy, ponieważ katalog systemowy opisuje obiekty znajdujące się w bazie, w której wykonywane jest zapytanie. Do powiązania indeksu z tabelą albo widokiem służy kolumna object_id, którą można zestawić z sys.objects.object_id, sys.tables.object_id lub sys.views.object_id.
Każdy indeks ma w obrębie swojego obiektu wartość index_id. Indeks o wartości index_id = 0 oznacza stertę, czyli tabelę bez indeksu klastrowanego; wiersz ten opisuje strukturę tabeli, mimo że nie jest klasycznym indeksem. Wartość index_id = 1 zwykle identyfikuje indeks klastrowany, jeżeli taki indeks istnieje. Indeksy nieklastrowane otrzymują kolejne identyfikatory. Sam numer nie określa jednak wszystkich właściwości indeksu, dlatego do interpretacji należy używać również kolumn opisujących jego typ, unikatowość, stan i sposób filtrowania.
Typy indeksów i ich właściwości zapisane w katalogu
Kolumna type przechowuje liczbowy identyfikator rodzaju indeksu, a type_desc podaje jego nazwę tekstową. W SQL Server można spotkać między innymi indeksy typu CLUSTERED, NONCLUSTERED, XML, SPATIAL, CLUSTERED COLUMNSTORE, NONCLUSTERED COLUMNSTORE, NONCLUSTERED HASH oraz indeksy używane przez określone funkcje silnika, takie jak indeksy zoptymalizowane pod kątem danych temporalnych. Rzeczywista dostępność poszczególnych typów zależy od wersji SQL Server, rodzaju obiektu i użytych funkcji bazy, dlatego raport powinien opierać się na wartościach zwróconych przez konkretną instancję.
Widok zawiera między innymi kolumny is_unique, is_primary_key, is_unique_constraint i is_disabled. is_unique informuje, czy indeks wymusza unikatowość klucza indeksu. Flagi is_primary_key oraz is_unique_constraint wskazują, czy indeks wspiera odpowiednio ograniczenie klucza głównego albo ograniczenie unikatowości. is_disabled pozwala wykryć indeks wyłączony logicznie dla operacji optymalizatora i utrzymania. Wyłączenie indeksu nie jest tym samym co jego usunięcie: definicja pozostaje w katalogu, ale indeks wymaga ponownego włączenia lub przebudowy, zanim będzie mógł normalnie uczestniczyć w obsłudze zapytań.
Ważne są również pola związane z filtrowaniem i magazynowaniem. Para has_filter oraz filter_definition wskazuje, czy jest to indeks filtrowany i jaki predykat ogranicza zbiór indeksowanych wierszy. fill_factor opisuje procentowe zapełnienie stron liści podczas tworzenia albo przebudowy indeksu, natomiast data_space_id wiąże indeks z przestrzenią danych, na przykład grupą plików lub partycjonowaniem. is_hypothetical identyfikuje indeks hipotetyczny utworzony do celów analizy, a nie jako zwykłą strukturę używaną produkcyjnie.
Łączenie sys.indexes z definicją klucza indeksu
sys.indexes opisuje indeks jako obiekt, ale nie przedstawia pełnej kolejności jego kolumn. Do tego celu służy sys.index_columns, które należy połączyć po object_id i index_id. Ten widok zawiera między innymi column_id, key_ordinal, is_descending_key, is_included_column oraz informacje o kolumnach używanych przez indeksy kolumnowe. Dzięki temu można odróżnić kolumny kluczowe od kolumn dołączonych przez INCLUDE, ustalić ich kolejność oraz sprawdzić, czy sortowanie klucza jest rosnące czy malejące.
Do odczytania nazw kolumn potrzebne jest dodatkowe połączenie z sys.columns. Dla indeksu klastrowanego lub nieklastrowanego kolumny z dodatnim key_ordinal tworzą klucz indeksu. Wiersze oznaczone przez is_included_column = 1 są przechowywane razem z indeksem, ale nie uczestniczą w jego kolejności wyszukiwania. W indeksach opartych na wyrażeniu nie występuje bezpośrednio nazwa wyrażenia jako zwykła kolumna tabeli; SQL Server może wykorzystywać w tym celu kolumnę obliczaną. Raportowanie powinno więc uwzględniać zarówno metadane indeksu, jak i strukturę obiektu, dla którego indeks został utworzony.
Praktyczne zapytanie diagnostyczne może pobrać OBJECT_SCHEMA_NAME(object_id), OBJECT_NAME(object_id), name, index_id, type_desc, is_unique, has_filter, filter_definition oraz is_disabled z sys.indexes. Taki odczyt pokazuje definicję i stan, ale nie zastępuje analizy użycia indeksu. Do sprawdzania, czy indeks jest faktycznie wykorzystywany przez zapytania, stosuje się osobne dynamiczne widoki zarządzania, między innymi sys.dm_db_index_usage_stats. Statystyki z tego źródła zależą od czasu działania instancji i mogą zostać wyzerowane po ponownym uruchomieniu SQL Server, dlatego nie należy interpretować pojedynczego odczytu jako pełnej historii obciążenia.
Wykorzystanie metadanych indeksów podczas przeglądu bazy
Odczyt sys.indexes pomaga wykrywać niespójności między oczekiwaną strukturą tabeli a jej rzeczywistą definicją. Można sprawdzić, czy tabela ma klucz główny, czy istnieją duplikujące się indeksy nieklastrowane, czy indeksy filtrujące mają właściwy predykat oraz czy któryś indeks został wyłączony. Przy porównywaniu indeksów trzeba uwzględnić kolejność kolumn, kierunek sortowania, kolumny INCLUDE, filtr, typ indeksu i partycjonowanie. Dwa indeksy o podobnym zestawie nazw mogą mieć inne działanie, jeżeli różnią się pierwszą kolumną klucza albo warunkiem filtrowania.
Wyniki z katalogu są również przydatne przy analizie problemów z wydajnością, ale nie powinny być traktowane jako samodzielna diagnoza. Obecność indeksu nie oznacza, że optymalizator wybierze go dla każdego zapytania. Decyzja zależy między innymi od predykatów, statystyk, selektywności danych, kosztu odczytu oraz wymaganych kolumn. Z kolei usunięcie indeksu wyłącznie na podstawie jego małego użycia może być błędne, jeżeli indeks obsługuje rzadką, lecz krytyczną operację albo zabezpiecza unikatowość danych. Bezpieczna ocena powinna łączyć definicję z sys.indexes, kolumny z sys.index_columns, schemat tabeli, plany zapytań i obserwowane statystyki obciążenia.
Podczas serwisowania komputera z lokalną instancją SQL Server metadane indeksów mogą pomóc ustalić, czy problem dotyczy samego silnika bazy, konfiguracji obiektu, czy ogólnego działania systemu. W praktyce należy najpierw wykonać odczytowe zapytania katalogowe, zapisać wynik i dopiero potem rozważać przebudowę, zmianę albo usunięcie indeksu. indexes wymaga zachowania kontekstu konkretnej bazy danych oraz uprawnień użytkownika wykonującego zapytanie.
