Udostępnij za pośrednictwem

Indeksy kolumnowe — wydajność zapytań

  • Artykuł

Dotyczy:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)SQL Database w Microsoft Fabric

Ten artykuł zawiera zalecenia dotyczące osiągania wysokiej wydajności zapytań przy użyciu indeksów kolumnowych.

Indeksy magazynu kolumn mogą osiągać do 100 razy lepszą wydajność obciążeń analizy i magazynowania danych oraz maksymalnie 10 razy lepszą kompresję danych niż tradycyjne indeksy magazynu wierszy. Te zalecenia ułatwiają zapytaniom osiągnięcie szybkiej wydajności zapytań, którą mają zapewnić indeksy magazynu kolumn.

Zalecenia dotyczące poprawy wydajności zapytań

Oto kilka zaleceń dotyczących osiągnięcia wysokiej wydajności, którą zapewniają zaprojektowane indeksy magazynu kolumnowego.

1. Organizowanie danych w celu wyeliminowania większej liczby grup wierszy z pełnego skanowania tabeli

  • Starannie wybierz kolejność wstawiania. W typowym przypadku w tradycyjnym magazynie danych dane są rzeczywiście wstawiane w kolejności czasu, a analiza jest wykonywana w wymiarze czasu. Na przykład analizowanie sprzedaży według kwartału. W przypadku tego rodzaju obciążenia eliminacja grupy wierszy odbywa się automatycznie. W programie SQL Server 2016 (13.x) można znaleźć liczby grup wierszy pominiętych w ramach przetwarzania zapytań.

  • Użyj indeksu klastrowanego magazynu wierszy. Jeśli typowy predykat zapytania znajduje się w kolumnie (na przykład C1) niepowiązanej z kolejnością wstawiania, utwórz indeks klastrowany magazynu wierszy w kolumnie C1. Następnie usuń klastrowany indeks wierszowy i utwórz klastrowany indeks kolumnowy. W przypadku jawnego utworzenia klastrowanego indeksu magazynu kolumn przy użyciu MAXDOP = 1wynikowy indeks klastrowanego magazynu kolumn jest idealnie uporządkowany w kolumnie C1. Jeśli określisz MAXDOP = 8, zobaczysz nakładanie się wartości w ośmiu grupach wierszy. W przypadku indeksu magazynu kolumn nieklastrowanego (NCCI), jeśli tabela ma indeks klastrowany typu rowstore, wiersze są już uporządkowane według klucza indeksu klastrowanego. W takim przypadku indeks magazynu kolumn nieklastrowanych jest również automatycznie uporządkowany. Indeks magazynu kolumn nie utrzymuje z natury kolejności wierszy. W miarę aktualizowania nowych wierszy lub starszych wierszy może być konieczne powtórzenie procesu, ponieważ wydajność zapytań analitycznych może się pogorszyć.

  • Implementowanie partycjonowania tabel. Indeks magazynu kolumn można podzielić na partycje, a następnie użyć eliminacji partycji, aby zmniejszyć liczbę grup wierszy do skanowania. Na przykład tabela faktów przechowuje zakupy dokonane przez klientów. Typowym wzorcem zapytań jest znalezienie kwartalnych zakupów według customer. W tym przypadku połącz kolumnę kolejności wstawień z partycjonowaniem na kolumnie customer. Każda partycja zawiera wiersze w przypadku każdego customer, uporządkowane zgodnie z kolejnością wstawiania. Należy również rozważyć użycie partycjonowania tabel, jeśli konieczne jest usunięcie starszych danych z magazynu kolumn. Wyłączenie i obcięcie partycji, które nie są potrzebne, jest efektywną strategią usuwania danych bez generowania fragmentacji.

  • Unikaj usuwania dużych ilości danych. Usuwanie skompresowanych wierszy z grupy wierszy nie jest operacją synchroniczną. Byłoby kosztowne zdekompresować grupę wierszy, usunąć wiersz, a następnie ponownie ją skompresować. W związku z tym podczas usuwania danych z skompresowanych grup wierszy te grupy wierszy są nadal skanowane, mimo że zwracają mniej wierszy. Jeśli liczba usuniętych wierszy w kilku grupach wierszy jest wystarczająco duża, aby można je było scalić w mniejszą liczbę grup wierszy, reorganizacja magazynu kolumn poprawia jakość indeksu, a wydajność zapytań się zwiększa. Jeśli proces usuwania danych zwykle opróżnia całe grupy wierszy, rozważ użycie partycjonowania tabel. Zamień partycje, które nie są już potrzebne, i przycinaj je, zamiast usuwać wiersze.

    Notatka

    Począwszy od wersji SQL Server 2019 (15.x), tuple-mover jest wspierany przez zadanie scalania w tle. To zadanie automatycznie kompresuje mniejsze grupy wierszy różnicowych OPEN, które istniały od jakiegoś czasu, zgodnie z progiem wewnętrznym, lub scala skompresowane grupy wierszy, z których usunięto dużą liczbę wierszy. To poprawia jakość indeksu magazynu danych kolumnowych z czasem. Jeśli wymagane jest usunięcie dużych ilości danych z indeksu magazynu kolumn, rozważ podzielenie tej operacji na mniejsze partie usuwania w czasie. Przetwarzanie wsadowe umożliwia zadanie scalania w tle do obsługi zadania scalania mniejszych grup wierszy i poprawia jakość indeksu. Następnie nie ma potrzeby planowania okien obsługi reorganizacji indeksu po usunięciu danych. Aby uzyskać więcej informacji na temat terminów i pojęć kolumnowego magazynu danych, zobacz Indeksy kolumnowego magazynu danych: Omówienie.

2. Planowanie wystarczającej ilości pamięci do równoległego tworzenia indeksów magazynu kolumn

Tworzenie indeksu magazynu kolumn jest domyślnie operacją równoległą, chyba że pamięć jest ograniczona. Równoległe tworzenie indeksu wymaga więcej pamięci niż szeregowe tworzenie indeksu. Gdy jest dostępna duża ilość pamięci, utworzenie indeksu kolumnowego zajmuje około 1,5 razy więcej czasu niż tworzenie drzewa B na tych samych kolumnach.

Pamięć wymagana do utworzenia indeksu magazynu kolumn zależy od liczby kolumn, liczby kolumn ciągów, stopnia równoległości (DOP) i cech danych. Jeśli na przykład tabela zawiera mniej niż milion wierszy, program SQL Server używa tylko jednego wątku do utworzenia indeksu magazynu kolumn.

Jeśli tabela zawiera więcej niż milion wierszy, ale program SQL Server nie może uzyskać wystarczającej ilości pamięci, aby utworzyć indeks przy użyciu funkcji MAXDOP, program SQL Server automatycznie zmniejsza MAXDOP zgodnie z potrzebami. W niektórych przypadkach DOP musi zostać zmniejszony do jednego, aby utworzyć indeks w ramach ograniczonej pamięci w dostępnego przydziału pamięci.

Od programu SQL Server 2016 (13.x) zapytanie zawsze działa w trybie wsadowym. W poprzednich wersjach wykonywanie wsadowe jest używane tylko wtedy, gdy DOP jest większy niż jeden.

Wyjaśnienie wydajności indeksów kolumnowych

Indeksy Columnstore osiągają wysoką wydajność zapytań, łącząc szybkie przetwarzanie wsadowe w pamięci z technikami, które znacznie zmniejszają wymagania dotyczące operacji wejścia/wyjścia. Ponieważ zapytania analityczne skanują dużą liczbę wierszy, zwykle są ograniczone przepustowością operacji we/wy, dlatego zmniejszenie liczby operacji we/wy podczas wykonywania zapytania jest kluczowe przy projektowaniu indeksów kolumnowych. Gdy dane są odczytywane do pamięci, kluczowe jest zmniejszenie liczby operacji w pamięci.

Indeksy magazynu kolumn zmniejszają operacje we/wy i optymalizują operacje w pamięci poprzez wysoką kompresję danych, eliminację magazynu kolumn, eliminację grupy wierszy i przetwarzanie wsadowe.

Kompresja danych

Indeksy magazynu kolumn osiągają do 10 razy większą kompresję danych niż indeksy magazynu wierszy. Znacznie zmniejsza to liczbę operacji we/wy wymaganych do wykonywania zapytań analitycznych, co zwiększa wydajność zapytań.

  • Indeksy magazynu kolumn odczytują skompresowane dane z dysku, co oznacza, że do pamięci musi być odczytywana mniejsza liczba bajtów danych.

  • Indeksy magazynu kolumn przechowują dane w skompresowanej postaci w pamięci, zmniejszając liczbę operacji we/wy, unikając odczytywania tych samych danych do pamięci. Na przykład przy 10-krotnej kompresji indeksy magazynu kolumn mogą przechowywać 10 razy więcej danych w pamięci w porównaniu z przechowywaniem danych w postaci nieskompresowanej. W przypadku większej ilości danych w pamięci jest bardziej prawdopodobne, że indeks magazynu kolumn znajduje dane, których potrzebuje w pamięci, bez ponoszenia niepotrzebnych operacji odczytu z dysku.

  • Indeksy magazynu kolumn kompresują dane według kolumn zamiast wierszy, osiągając wysokie współczynniki kompresji i zmniejszając rozmiar danych przechowywanych na dysku. Każda kolumna jest kompresowana i przechowywana niezależnie. Dane w kolumnie zawsze mają ten sam typ danych i zwykle mają podobne wartości. Techniki kompresji danych magazynu kolumn doskonale nadają się do osiągnięcia wyższych współczynników kompresji, gdy wartości są podobne.

Na przykład tabela faktów przechowuje adresy klientów i zawiera kolumnę dla country-region. Łączna liczba możliwych wartości jest mniejsza niż 200. Niektóre z tych wartości są powtarzane wiele razy. Jeśli tabela faktów zawiera 100 milionów wierszy, kolumna country-region jest łatwa do skompresowania i wymaga mało miejsca. Kompresja wiersz po wierszu nie może wykorzystać podobieństwa wartości kolumn w ten sposób i musi używać większej liczby bajtów do kompresowania wartości w kolumnie country-region.

Eliminacja kolumn

Indeksy kolumnowe pomijają odczytywanie kolumn, które nie są wymagane dla wyniku zapytania. Eliminacja kolumn dodatkowo zmniejsza operacje we/wy na potrzeby wykonywania zapytań i w związku z tym zwiększa wydajność zapytań.

  • Eliminacja kolumn jest możliwa, ponieważ dane są zorganizowane i kompresowane według kolumny. Natomiast gdy dane są przechowywane w wierszu po wierszu, wartości kolumn w każdym wierszu są fizycznie przechowywane razem i nie można ich łatwo rozdzielić. Procesor zapytań musi odczytać cały wiersz, aby pobrać określone wartości kolumn, co zwiększa liczbę operacji we/wy, ponieważ dodatkowe dane są niepotrzebnie ładowane do pamięci.

Jeśli na przykład tabela zawiera 50 kolumn, a zapytanie używa tylko pięciu z tych kolumn, indeks magazynu kolumn pobiera tylko pięć kolumn z dysku. Pomija odczytywanie w pozostałych 45 kolumnach, zmniejszając operacje wejścia/wyjścia o kolejne 90%, przy założeniu, że wszystkie kolumny mają podobny rozmiar. Jeśli te same dane są przechowywane w magazynie wierszy, procesor zapytań musi odczytać pozostałe 45 kolumn.

Eliminacja grupy wierszy

W przypadku skanowania pełnej tabeli duża część danych zwykle nie jest zgodna z kryteriami predykatu zapytania. Za pomocą metadanych indeks magazynu kolumnowego może pominąć odczytywanie grup wierszy, które nie zawierają danych wymaganych dla wyniku zapytania, wszystko to bez rzeczywistego I/O. Ta możliwość, nazywana eliminacją grupy wierszy, zmniejsza operacje we/wy w przypadku pełnego skanowania tabeli i w związku z tym poprawia wydajność zapytań.

Kiedy indeks magazynu kolumn musi wykonać pełne skanowanie tabeli?

Począwszy od programu SQL Server 2016 (13.x), można utworzyć co najmniej jeden zwykły, nieklastrowany magazyn wierszy lub indeksy B-tree w klastrowanym indeksie magazynu kolumn. Nieklastrowane indeksy drzewa B mogą przyspieszyć zapytanie, które ma predykat równości lub predykat z małym zakresem wartości. W przypadku bardziej skomplikowanych predykatów optymalizator zapytań może wybrać pełne skanowanie tabeli. Bez możliwości pomijania grup wierszy pełne skanowanie tabeli może być czasochłonne, szczególnie w przypadku dużych tabel.

Kiedy zapytanie analityczne korzysta z eliminacji grupy wierszy na potrzeby skanowania w pełnej tabeli?

Na przykład firma detaliczna modeluje swoje dane sprzedażowe przy użyciu tabeli faktów z klastrowanym indeksem kolumnowym. Każda nowa sprzedaż przechowuje różne atrybuty transakcji, w tym datę sprzedaży produktu. Co ciekawe, mimo że indeksy magazynu kolumn nie gwarantują posortowanej kolejności, wiersze w tej tabeli są ładowane w kolejności sortowania dat. Wraz z upływem czasu ta tabela rośnie. Chociaż firma detaliczna może przechowywać dane sprzedaży przez ostatnie 10 lat, zapytanie analityczne może wymagać obliczenia agregacji tylko w ostatnim kwartale. Indeksy magazynów kolumnowych mogą wyeliminować konieczność dostępu do danych z poprzednich 39 kwartałów, poprzez analizę metadanych kolumny z datą. Jest to 97% zmniejszenie ilości danych odczytywanych do pamięci i przetwarzanych.

Które grupy wierszy są pomijane w pełnym skanowaniu tabeli?

Aby określić grupy wierszy do wyeliminowania, indeks magazynu kolumn używa metadanych do przechowywania minimalnych i maksymalnych wartości poszczególnych segmentów kolumn dla każdej grupy wierszy. Jeśli żaden z zakresów segmentów kolumn nie spełnia warunków predykatu zapytania, pomijana jest cała grupa wierszy bez wykonywania żadnych rzeczywistych operacji wejścia/wyjścia. Działa to, ponieważ dane są zwykle ładowane w kolejności posortowanej. Chociaż sortowanie wierszy nie jest gwarantowane, podobne wartości danych często znajdują się w tej samej grupie wierszy lub w sąsiedniej grupie wierszy.

Aby uzyskać więcej informacji na temat grup wierszy, zobacz Wytyczne dotyczące projektowania indeksu kolumnowego.

Wykonywanie trybu wsadowego

Wykonywanie w trybie wsadowym przetwarza wiersze w grupach, zwykle do 900 naraz, aby zwiększyć wydajność. Na przykład zapytanie SELECT SUM(Sales) FROM SalesData oblicza łączną sprzedaż z tabeli SalesData. W trybie wsadowym silnik zapytań przetwarza dane w grupach po 900 wierszy. Takie podejście zmniejsza koszt dostępu do metadanych i inne typy obciążeń przez rozłożenie ich we wszystkich wierszach w partii, a nie naliczenie obciążenia dla każdego wiersza. Ponadto tryb wsadowy działa z skompresowanymi danymi, gdy jest to możliwe i usuwa niektóre operatory wymiany używane w trybie wiersza, co znacznie przyspiesza wykonywanie zapytań analitycznych.

Nie wszystkie operatory wykonywania zapytań można wykonywać w trybie wsadowym. Na przykład operacje języka manipulowania danymi (DML), takie jak wstawianie, usuwanie lub aktualizowanie, są wykonywane jeden wiersz jednocześnie. Operator trybu wsadowego, taki jak Skanowanie, Złączenie, Agregacja, Sortowanie i inne, może zwiększyć wydajność zapytania. Ponieważ indeks magazynujący kolumny został wprowadzony w programie SQL Server 2012 (11.x), istnieją nieustanne starania na rzecz rozszerzenia operatorów, które można wykonać w trybie wsadowym. W poniższej tabeli przedstawiono operatory, które działają w trybie wsadowym zgodnie z wersją produktu.

Operatory trybu wsadowego W przypadku użycia SQL Server 2012 (11.x) SQL Server 2014 (12.x) SQL Server 2016 (13.x) i Baza danych SQL1 Komentarze
Operacje DML (wstawianie, usuwanie, aktualizowanie, scalanie) Nie Nie Nie DML nie jest operacją trybu wsadowego, ponieważ nie jest równoległa. Po włączeniu przetwarzania wsadowego w trybie seryjnym, nie zauważamy znaczących korzyści z umożliwienia przetwarzania DML w trybie wsadowym.
skanowanie indeksu magazynu kolumn SKAN Niedostępne tak tak W przypadku indeksów magazynu kolumn możemy wypchnąć predykat do węzła SCAN.
skanowanie indeksu magazynu kolumn (nieklastrowane) SKAN tak tak tak tak
przeszukiwanie indeksu Niedostępne Niedostępne Nie Przeprowadzamy operację wyszukiwania za pomocą indeksu nieklastrowanego drzewa B w trybie wiersza.
obliczyć skalar Wyrażenie, które oblicza wartość skalarną. tak tak tak Podobnie jak wszystkie operatory trybu wsadowego, istnieją pewne ograniczenia dotyczące typu danych.
Łączenie UNIA I UNIA WSZYSTKIE Nie tak tak
filtr Stosowanie predykatów tak tak tak
Dopasowanie skrótu hasz Funkcje agregujące oparte na skrótach, zewnętrzne sprzężenie skrótu, prawe sprzężenie skrótu, lewe sprzężenie skrótu, prawe sprzężenie wewnętrzne, lewe sprzężenie wewnętrzne tak tak tak Ograniczenia agregacji: brak wartości minimalnej/maksymalnej dla ciągów. Dostępne funkcje agregacji to suma/liczba/średnia/minimum/maksimum.
Ograniczenia dotyczące sprzężenia: brak niezgodnych sprzężeń typów w typach innych niż liczba całkowita.
łączanie przez scalanie Nie Nie Nie
zapytania wielowątkowe tak tak tak
pętle zagnieżdżone Nie Nie Nie
zapytania jednowątkowe uruchomione przy MAXDOP 1 Nie Nie tak
zapytania jednowątkowe z planem zapytania szeregowego Nie Nie tak
rodzaj Klauzula ORDER BY w funkcji SCAN z indeksem kolumnowym. Nie Nie tak
sortowanie od góry Nie Nie tak
agregacje okien Niedostępne Niedostępne tak Nowy operator w programie SQL Server 2016 (13.x).

1 dotyczy programu SQL Server 2016 (13.x), warstw Premium usługi SQL Database, warstw Standard — S3 i wyższych, wszystkich warstw rdzeni wirtualnych oraz systemu platformy analizy (PDW)

Aby uzyskać więcej informacji, zobacz przewodnik po architekturze przetwarzania zapytań .

Zagregowane wypychanie

Normalna ścieżka wykonywania dla obliczeń agregujących polega na pobieraniu zakwalifikowanych wierszy z węzła SCAN i agregowaniu wartości w trybie wsadowym. Chociaż zapewnia to dobrą wydajność, począwszy od programu SQL Server 2016 (13.x), można wypchnąć operację agregacji do węzła SCAN. Wypychanie agregowane zwiększa wydajność obliczeń agregacji według kolejności wielkości na podstawie wykonywania trybu wsadowego, pod warunkiem spełnienia następujących warunków:

  • Agregacje to MIN, MAX, SUM, COUNT i COUNT(*).
  • Operator agregacji musi być umieszczony na górze węzła SCAN lub węzła SCAN z GROUP BY.
  • Ta agregacja nie jest odrębną agregą.
  • Kolumna agregacji nie jest kolumną ciągu.
  • Kolumna agregacji nie jest kolumną wirtualną.
  • Typ danych wejściowych i wyjściowych musi być jednym z następujących elementów i musi mieścić się w ciągu 64 bitów:
    • tinyint, int, bigint, smallint, bit
    • smallmoney, pieniędzy, dziesiętnych i liczbowych z dokładnością <= 18
    • smalldate, date, datetime, datetime2, godzina

Na przykład zagregowane wypychanie odbywa się w obu następujących zapytaniach:

SELECT  productkey, SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI
GROUP BY productkey;
    
SELECT  SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI;

Wypychanie predykatu ciągów

Podczas projektowania schematu magazynu danych zalecane modelowanie schematu polega na użyciu schematu gwiazdy lub płatka śniegu składającego się z co najmniej jednej tabeli faktów i wielu tabel wymiarów.

Napiwek

Tabela faktów przechowuje miary biznesowe lub transakcje, a tabela wymiarów przechowuje wymiary, w których należy analizować fakty. Aby uzyskać więcej informacji na temat modelowania wymiarowego, zobacz Modelowanie wymiarowe w usłudze Microsoft Fabric.

Na przykład fakt może być rekordem reprezentującym sprzedaż określonego produktu w określonym regionie, podczas gdy wymiar reprezentuje zestaw regionów, produktów itd. Tabele faktów i wymiarów są połączone za pośrednictwem relacji klucza podstawowego/obcego. Najczęściej używane zapytania analityczne łączą co najmniej jedną tabelę wymiarów z tabelą faktów.

Rozważmy tabelę wymiarów Products. Typowy klucz podstawowy jest ProductCode, często reprezentowany jako ciąg. Aby zwiększyć wydajność zapytań, najlepszym rozwiązaniem jest utworzenie klucza zastępczego, zazwyczaj kolumny typu całkowitego, do odwołań do wiersza w tabeli wymiarów z tabeli faktów.

Indeks magazynu kolumn uruchamia zapytania analityczne ze sprzężeniami i predykatami obejmującymi klucze liczbowe lub całkowite. Program SQL Server 2016 (13.x) znacznie poprawił wydajność zapytań analitycznych z kolumnami opartymi na ciągach, wypychając predykaty z kolumnami ciągów do węzła SCAN.

Wyliczanie predykatów dla ciągów znaków wykorzystuje słownik główny/pomocniczy utworzony dla kolumn, aby poprawić wydajność zapytań. Rozważmy na przykład segment kolumny ciągu w grupie wierszy składającej się z 100 odrębnych wartości ciągu. Każda unikatowa wartość ciągu jest przywoływana średnio 10 000 razy, przy założeniu, że mamy milion wierszy. W przypadku wypychania predykatu ciągu wykonywanie zapytania oblicza predykat względem wartości w słowniku. Jeśli predykat kwalifikuje się, wszystkie wiersze odwołujące się do wartości słownika są automatycznie kwalifikowane. Poprawia to wydajność na dwa sposoby:

  • Zwracany jest tylko kwalifikowany wiersz, zmniejszając liczbę wierszy, które muszą wypłynąć z węzła skanowania.
  • Liczba porównań ciągów jest ograniczona. W tym przykładzie wymagane jest tylko 100 porównań ciągów w porównaniu z 1 milionami porównań. Istnieją pewne ograniczenia:
    • Brak operacji predykatu typu 'string' dla grupy wierszy delta. Brak słownika dla kolumn w grupach wierszy delta.
    • Brak obsługi predykatów dla ciągów, jeśli rozmiar słownika przekracza 64 KB wpisów.
    • Wyrażenie oceniające wartości null nie jest obsługiwane.

Eliminacja segmentów

Wybór typu danych może mieć znaczący wpływ na wydajność zapytań na podstawie typowych predykatów filtrów dla zapytań w indeksie magazynu kolumn.

W danych kolumnowego magazynowania grupy wierszy składają się z segmentów kolumn. Istnieją metadane z każdym segmentem, aby umożliwić szybką eliminację segmentów bez ich odczytywania. Ta eliminacja segmentu ma zastosowanie do typów danych liczbowych, daty i godziny, a datetimeoffset typ danych ze skalowaniem mniejszym lub równym dwóm. Począwszy od SQL Server 2022 (16.x), funkcje eliminacji segmentów zostają rozszerzone na typy danych string, binary, guid oraz typ danych datetimeoffset dla skali większej niż dwa.

Po uaktualnieniu do wersji programu SQL Server obsługującej eliminację minimalnego/maksymalnego segmentu ciągu (SQL Server 2022 (16.x) i nowszych), indeks magazynu kolumn nie czerpie korzyści z tej funkcji, dopóki nie zostanie przebudowany przy użyciu ALTER INDEX REBUILD lub CREATE INDEX WITH (DROP_EXISTING = ON).

Eliminacja segmentów nie ma zastosowania do typów danych LOB, takich jak maksymalne długości typu danych.

Obecnie tylko programy SQL Server 2022 (16.x) i nowsze obsługują eliminację grup wierszy w klastrowanym magazynie kolumn dla prefiksu predykatów LIKE, na przykład column LIKE 'string%'. Eliminacja segmentów nie jest obsługiwana dla użycia LIKEniebędącego prefiksem, takich jak column LIKE '%string'.

indeksy uporządkowanego magazynu kolumn również korzystać z eliminacji segmentów, szczególnie w przypadku kolumn ciągów. W uporządkowanych indeksach magazynu kolumn eliminacja segmentu dla pierwszej kolumny klucza indeksu jest najbardziej skuteczna, ponieważ ta kolumna jest posortowana. Wzrost wydajności spowodowany eliminacją segmentów w innych kolumnach w tabeli jest mniej przewidywalny. Aby uzyskać więcej informacji na temat indeksów kolumnowych, zobacz Używanie uporządkowanego indeksu kolumnowego dla dużych tabel w magazynach danych. Aby uzyskać informacje o dostępności uporządkowanego indeksu kolumnowego, zobacz Dostępność uporządkowanego indeksu kolumnowego.

Korzystając z opcji połączenia zapytania SET STATISTICS IO, można wyświetlić eliminację segmentów w praktyce. Szukaj danych wyjściowych podobnych do poniższych, aby wskazać, że wystąpiła eliminacja segmentu. Grupy wierszy składają się z segmentów kolumn, więc może to wskazywać na eliminację segmentów. Następujący przykład danych wyjściowych zapytania SET STATISTICS IO - około 83 danych% zostało pominiętych przez zapytanie.

...
Table 'FactResellerSalesPartCategoryFull'. Segment reads 16, segment skipped 83.
...

Powiązana zawartość