sys.index_columns zawiera przypisanie kolumn do poszczególnych indeksów wraz z ich kolejnością.
Widok sys.index_columns jako mapa struktury indeksów
Widok katalogowy sys.index_columns należy do grupy obiektów systemowych Microsoft SQL Server i służy do odczytywania zależności między indeksami a kolumnami tabel lub widoków. W praktyce pozwala ustalić, jakie pola zostały użyte przy budowie konkretnego indeksu, w jakiej kolejności występują oraz czy dana kolumna jest traktowana jako element klucza indeksu, czy tylko jako kolumna dołączona. Jest to informacja przydatna podczas analizy wydajności zapytań, sprawdzania projektu bazy danych, porządkowania indeksów i przygotowywania zmian w schemacie.
Sam widok nie opisuje całego indeksu. Do uzyskania pełniejszego obrazu zwykle łączy się go z sys.indexes, który przedstawia właściwości indeksu, oraz z sys.objects, sys.tables albo sys.schemas, które pomagają ustalić nazwę obiektu i jego schemat. Informacje o typach danych kolumn można pobrać z sys.columns, a o dodatkowych właściwościach kolumn z sys.types. Dzięki temu można przejść od samego numeru identyfikacyjnego do czytelnego opisu: tabela, indeks, kolumna, pozycja w kluczu oraz sposób wykorzystania pola.
Ważne jest rozróżnienie między kolejnością kolumn w tabeli a kolejnością kolumn w indeksie. Tabela może mieć pola zapisane w jednym układzie, natomiast indeks może zaczynać się od zupełnie innej kolumny. To właśnie kolejność indeksowa ma znaczenie przy ocenie, czy zapytanie może efektywnie wykorzystać początkowy fragment klucza. sys.index_columns pomaga więc odtworzyć rzeczywisty układ indeksu bez polegania na nazwie indeksu lub na założeniach wynikających z projektu aplikacji.
Widok sys.index_columns na tle innych informacji katalogowych
W SQL Server indeks może być zbudowany z kolumn kluczowych oraz z kolumn dołączonych za pomocą klauzuli INCLUDE. Kolumny kluczowe uczestniczą w organizacji struktury indeksu i wpływają na możliwość wyszukiwania, sortowania oraz zakresowego odczytu danych. Kolumny dołączone nie rozszerzają klucza w taki sam sposób, lecz pozwalają przechować dodatkowe wartości potrzebne do obsłużenia zapytania bez odwoływania się do tabeli bazowej. Przy analizie planu wykonania to rozróżnienie ma duże znaczenie, ponieważ indeks pokrywający zapytanie może być zbudowany zarówno z pól kluczowych, jak i dołączonych.
Jednym z istotnych pól widoku jest index_column_id. Określa ono pozycję kolumny w danym indeksie. Nie należy mylić go z column_id, które wskazuje położenie kolumny w strukturze tabeli. Różnica między tymi wartościami jest naturalna i często występuje. Do rozpoznania konkretnego indeksu używa się index_id, natomiast object_id wskazuje obiekt, w którym indeks został utworzony. Dopiero połączenie tych identyfikatorów pozwala poprawnie odczytać kontekst rekordu.
W przypadku indeksu zwykłego kolejność klucza może być odczytywana przez key_ordinal. Wartość tego pola wskazuje miejsce kolumny w kluczu, a wartość zerowa jest typowa dla kolumny dołączonej, która nie należy do klucza wyszukiwania. Pole is_included_column ułatwia bezpośrednie rozpoznanie tego przypadku. Dla indeksów kolumnowych oraz niektórych wyspecjalizowanych struktur mogą pojawić się odmienne zasady interpretacji poszczególnych pól, dlatego wynik powinien być czytany razem z typem indeksu zwróconym przez sys.indexes.
Przydatne bywa również pole is_descending_key, które informuje o kierunku uporządkowania kolumny kluczowej. Ma ono znaczenie wtedy, gdy indeks został zdefiniowany z kierunkiem rosnącym lub malejącym. Sam kierunek nie przesądza jeszcze o jakości indeksu, ale może mieć wpływ na dopasowanie do sortowania wykonywanego przez zapytanie. W analizie warto zestawić go z klauzulami ORDER BY, warunkami zakresowymi oraz kolejnością kolumn w predykatach.
Widok sys.index_columns i typowe problemy podczas analizy
Jednym z częstych błędów jest wyszukiwanie indeksu wyłącznie po jego nazwie. Nazwy mogą być podobne, mogą zostać zmienione albo mogą różnić się między środowiskiem testowym a produkcyjnym. Bezpieczniejsze jest filtrowanie po object_id i index_id, a następnie dołączenie nazwy z sys.indexes. Pozwala to uniknąć pomieszania indeksów należących do różnych tabel, zwłaszcza gdy w wielu obiektach zastosowano podobne konwencje nazewnicze.
Innym problemem jest błędne traktowanie wszystkich rekordów jako kolumn kluczowych. Indeks zawierający kilka pól może mieć część kluczową oraz zestaw pól INCLUDE. Jeżeli nie zostanie sprawdzone is_included_column lub key_ordinal, można dojść do niepoprawnego wniosku o kolejności klucza. Taki błąd wpływa później na ocenę selektywności indeksu, przewidywanie jego użycia i decyzję o ewentualnej przebudowie.
Problemy pojawiają się również przy indeksach tworzonych na wyrażeniach, kolumnach obliczanych lub obiektach o nietypowej strukturze. W takich sytuacjach prezentowana informacja może wymagać dodatkowego sprawdzenia w definicji tabeli, definicji kolumny obliczanej albo skryptach wdrożeniowych. Warto pamiętać, że widok katalogowy pokazuje stan aktualny. Nie jest dziennikiem zmian i samodzielnie nie wyjaśnia, kiedy indeks powstał, przez kogo został zmodyfikowany ani z jakiego powodu przyjęto określony układ.
Nie powinno się także usuwać indeksu tylko dlatego, że nie jest widoczny jako używany w krótkim fragmencie obserwacji. Brak odczytów może wynikać z małej liczby zapytań, sezonowości danych, zmiennych parametrów lub niewystarczającego czasu monitorowania. Najpierw należy porównać definicję indeksu z rzeczywistymi zapytaniami, planami wykonania i statystykami użycia. sys.index_columns dostarcza elementu układanki, lecz nie zastępuje pełnej diagnostyki.
Widok sys.index_columns w codziennej diagnostyce bazy
Praktyczne zapytanie kontrolne powinno zwracać nazwę schematu, tabeli, indeksu, kolumny, pozycję w kluczu, informację o dołączeniu oraz kierunek sortowania. Przydatny jest układ uporządkowany najpierw po obiekcie, potem po indeksie i na końcu po pozycji kolumny. Dzięki temu wynik można czytać podobnie jak definicję indeksu. W przypadku kolumn dołączonych pozycja kluczowa może nie mieć znaczenia, dlatego powinny być wyraźnie oznaczone.
Podczas przeglądu indeksów można zwrócić uwagę na kilka sygnałów ostrzegawczych:
- powtarzające się prefiksy kluczy w wielu indeksach tej samej tabeli,
- indeksy o podobnym zestawie kolumn, lecz różniące się pojedynczym polem dołączonym,
- kolumny umieszczone w kluczu mimo niewielkiej selektywności,
- bardzo szerokie zestawy kolumn dołączonych, zwiększające rozmiar indeksu,
- kolejność klucza niedopasowana do najczęściej wykonywanych filtrów i sortowań,
- definicje odbiegające od dokumentacji albo od skryptów utrzymywanych w repozytorium.
Wynik warto porównywać z planem wykonania konkretnego zapytania. Jeżeli plan korzysta z wyszukiwania po pierwszej kolumnie indeksu, pozycja tej kolumny ma bezpośrednie znaczenie. Jeżeli zapytanie filtruje po polu występującym dopiero dalej, indeks może być wykorzystywany w ograniczonym zakresie albo może zostać pominięty. Nie oznacza to automatycznie, że sama kolejność jest błędna. Decyzja zależy od rozkładu danych, częstotliwości zapytań, kosztu utrzymania indeksu oraz operacji zapisu wykonywanych na tabeli.
Przy zmianach schematu należy sprawdzić, czy modyfikowana kolumna nie występuje w indeksach jako klucz lub kolumna dołączona. Zmiana typu, długości albo nullowalności może mieć konsekwencje dla indeksu, ograniczeń i planów wykonania. Odczyt sys.index_columns przed wdrożeniem pomaga wykryć zależności, których nie widać w prostym skrypcie zmiany tabeli. Dobrą praktyką jest zapisanie wyniku przed zmianą oraz ponowne wykonanie tego samego zapytania po wdrożeniu.
Kiedy sprawdzać widok sys.index_columns i skorzystać z pomocy
Analiza sys.index_columns jest szczególnie uzasadniona wtedy, gdy zapytania zaczynają działać wolniej, plan wykonania zmienia się po modyfikacji tabeli, pojawiają się blokady podczas zapisu albo nie jest jasne, który indeks odpowiada za obsługę danego filtra. Warto sięgnąć po ten widok także przed porządkowaniem indeksów, przenoszeniem bazy do innego środowiska i porównywaniem dwóch schematów. Pomocne jest zebranie nazwy tabeli, nazwy indeksu, tekstu zapytania oraz planu wykonania, ponieważ sama lista kolumn nie zawsze pozwala rozstrzygnąć przyczynę problemu.
W sytuacji, gdy potrzebne jest sprawdzenie konfiguracji komputera, oprogramowania bazodanowego albo zależności między aplikacją a SQL Server, można skontaktować się z firmą Warszawskie Pogotowie Komputerowe 24/7 pod numerem +48 22 100 48 29. Przed zgłoszeniem warto przygotować opis objawów, moment pojawienia się problemu i informacje o ostatnich zmianach. Ułatwia to uporządkowanie diagnostyki, rozdzielenie problemu z definicją indeksu od problemu z zapytaniem oraz ocenę, czy potrzebna jest analiza samej bazy, systemu operacyjnego czy aplikacji.
Najważniejszą zasadą pozostaje interpretowanie widoku katalogowego w szerszym kontekście. sys.index_columns pokazuje przypisanie pól do indeksów i ich układ, ale nie mówi samodzielnie, czy indeks jest potrzebny, poprawnie dobrany albo aktualnie wykorzystywany. Do takiej oceny potrzebne są jeszcze definicje obiektów, statystyki użycia, plany wykonania, charakter zapytań i obserwacja operacji zapisu. Właściwe połączenie tych informacji pozwala podejmować zmiany na podstawie danych, a nie wyłącznie na podstawie nazw indeksów lub pojedynczego rekordu w katalogu systemowym.
