Indeksy o type_desc równym COLUMNSTORE w sys.indexes wskazują struktury kolumnowe zamiast klasycznych wierszowych.
Jak interpretować type_desc = COLUMNSTORE w widoku sys.indexes
W Microsoft SQL Server widok katalogowy sys.indexes opisuje indeksy utworzone dla tabel i widoków. Wartość COLUMNSTORE w kolumnie type_desc oznacza, że dany indeks wykorzystuje kolumnowy sposób organizacji danych. Nie jest to klasyczny indeks wierszowy typu B-tree, w którym rekordy są przechowywane przede wszystkim według kolejnych wierszy tabeli. Indeks kolumnowy grupuje wartości poszczególnych kolumn, dzięki czemu silnik może odczytywać tylko kolumny potrzebne do wykonania zapytania.
Samo znalezienie wiersza z type_desc = COLUMNSTORE nie wskazuje jeszcze, czy indeks obejmuje całą tabelę, czy tylko wybrane kolumny. Do rozróżnienia rodzaju indeksu służy również kolumna type. W SQL Server wartość odpowiadająca indeksowi clustered columnstore jest opisywana jako CLUSTERED COLUMNSTORE, natomiast indeks nonclustered columnstore jako NONCLUSTERED COLUMNSTORE. W praktyce podczas analizy należy sprawdzać razem object_id, index_id, name, type oraz type_desc.
Różnica między clustered i nonclustered columnstore
Clustered columnstore index staje się główną strukturą przechowywania danych tabeli. Dane są organizowane w grupy wierszy, a wartości są kompresowane kolumnowo. Taki model jest przeznaczony przede wszystkim do zapytań analitycznych, które odczytują dużą liczbę rekordów, ale korzystają z ograniczonego zestawu kolumn. SQL Server może wtedy pominąć kolumny nieużywane w zapytaniu oraz zastosować eliminację grup wierszy na podstawie metadanych opisujących zakres przechowywanych wartości.
Nonclustered columnstore index jest dodatkową strukturą utworzoną na tabeli, która może nadal posiadać klasyczny indeks klastrowany albo stertę. Zawiera wybrane kolumny i służy do przyspieszania określonych zapytań analitycznych bez zmiany podstawowego sposobu przechowywania tabeli. Zakres kolumn indeksu można sprawdzić w widoku sys.index_columns, łącząc go z sys.columns oraz sys.tables. Dzięki temu można ustalić, czy indeks obejmuje kolumny używane w filtrach, grupowaniu, agregacji albo projekcji zapytania.
Indeks kolumnowy nie jest automatycznie korzystny dla każdego obciążenia. Zapytania modyfikujące pojedyncze wiersze, często wyszukujące po kluczu lub wymagające szybkiego dostępu do kompletnego rekordu mogą lepiej wykorzystywać indeksy wierszowe. Columnstore wprowadza również dodatkowe koszty utrzymania, ponieważ przy zmianach danych silnik musi aktualizować odpowiednią strukturę. Ocena powinna więc uwzględniać rzeczywiste zapytania, plan wykonania, rozkład danych i częstotliwość operacji INSERT, UPDATE oraz DELETE.
Powiązane widoki katalogowe i kontrola poprawności
Analiza wpisu w sys.indexes powinna zaczynać się od ustalenia obiektu, którego dotyczy indeks. Kolumna object_id pozwala połączyć wynik z sys.tables albo sys.views. Kolumna index_id identyfikuje indeks w obrębie danego obiektu, a name pokazuje jego nazwę, jeżeli została nadana. Warto także sprawdzić is_disabled, ponieważ indeks wyłączony może być widoczny w katalogu, ale nie będzie normalnie wykorzystywany przez optymalizator zapytań.
Informacje o kolumnach indeksu znajdują się w sys.index_columns. Przy indeksach columnstore istotne jest sprawdzenie, które kolumny zostały objęte strukturą oraz czy indeks ma charakter clustered czy nonclustered. Uzupełnieniem katalogu systemowego są dynamiczne widoki zarządzania związane z columnstore, między innymi sys.dm_db_column_store_row_group_physical_stats. Pozwalają one analizować stan grup wierszy, ich liczbę, kompresję oraz obecność wierszy oczekujących na kompresję albo znajdujących się w deltastore.
Nie należy utożsamiać samej wartości type_desc z dowodem, że indeks działa prawidłowo albo że jest używany przez konkretne zapytanie. Do sprawdzenia wykorzystania potrzebne są plany wykonania oraz statystyki pracy instancji, na przykład dane z dynamicznych widoków dotyczących użycia indeksów. Należy też rozróżnić istnienie indeksu od jego skuteczności: katalog potwierdza definicję obiektu, lecz nie potwierdza poprawności projektu zapytań, aktualności statystyk ani opłacalności utrzymywania danej struktury.
Znaczenie wpisu columnstore podczas diagnostyki komputera
Widok sys.indexes należy do katalogu systemowego SQL Server, dlatego jego interpretacja dotyczy konfiguracji i działania konkretnego silnika bazy danych, a nie sprzętowego typu dysku lub pamięci masowej. Jeżeli analiza wykazuje indeks columnstore, trzeba zestawić ten fakt z charakterem aplikacji: zapytaniami raportowymi, agregacjami, filtrowaniem dużych zbiorów oraz operacjami zmieniającymi dane. Problemy z wydajnością mogą wynikać zarówno z niewłaściwego indeksu, jak i z blokad, przeciążenia procesora, ograniczeń pamięci, wydajności dysku albo nieefektywnego planu wykonania.
W środowisku lokalnym lub biurowym diagnostyka komputera może obejmować sprawdzenie, czy objawy opóźnień rzeczywiście pochodzą z zapytań SQL Server, czy tylko ujawniają problem z systemem operacyjnym, nośnikiem danych, siecią albo aplikacją kliencką. Bezpieczna ocena wymaga zachowania spójności danych i wykonywania zmian dopiero po ustaleniu zależności między strukturą indeksu a planami zapytań. Samo usunięcie indeksu columnstore na podstawie jego obecności w sys.indexes nie jest poprawną metodą diagnostyczną, ponieważ może pogorszyć działanie zapytań analitycznych.
Analiza samego SQL Server wymaga konfiguracji silnika, zapytań i struktur katalogowych właściwych dla tego oprogramowania. Wpis type_desc = COLUMNSTORE jest punktem wyjścia do takiej analizy: wskazuje rodzaj indeksu, ale dopiero powiązanie z obiektem, kolumnami, grupami wierszy i planem wykonania pozwala sformułować techniczny wniosek.
