Udostępnij za pośrednictwem

Indeksy kolumnowe — wskazówki dotyczące projektowania

  • Artykuł

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

Zalecenia wysokiego poziomu dotyczące projektowania indeksów columnstore. Kilka dobrych decyzji projektowych pomaga osiągnąć wysoką kompresję danych i wydajność zapytań, do których zapewnienia zostały zaprojektowane indeksy kolumnowe.

Warunki wstępne

W tym artykule założono, że znasz architekturę i terminologię columnstore. Aby uzyskać więcej informacji, zobacz Indeksy Magazynu Kolumn: Omówienie i Architektura Indeksu Magazynu Kolumn.

Znajomość wymagań dotyczących danych

Przed zaprojektowaniem indeksu kolumnowego należy jak najlepiej zrozumieć wymagania dotyczące danych. Na przykład zapoznaj się z odpowiedziami na następujące pytania:

  • Jak duża jest moja tabela?
  • Czy moje zapytania wykonują głównie analizę, która skanuje duże zakresy wartości? Indeksy columnstore są zaprojektowane do dobrego działania przy skanowaniu dużych zakresów zamiast wyszukiwać określone wartości.
  • Czy moje obciążenie wykonuje wiele aktualizacji i usuwania? Indeksy kolumnowe działają dobrze, gdy dane są stabilne. Zapytania powinny aktualizować i usuwać mniej niż 10% wierszy.
  • Czy mam tabele faktów i wymiarów dla magazynu danych?
  • Czy muszę przeprowadzić analizę obciążenia transakcyjnego? Jeśli tak, sprawdź wskazówki dotyczące projektowania kolumnowej bazy danych do analizy operacyjnej w czasie rzeczywistym.

Możliwe, że indeks kolumnowy nie jest potrzebny. Tabele magazynujące dane wierszowe, znane również jako B-drzewa, ze stosami lub indeksami klastrowymi, najlepiej sprawdzają się przy zapytaniach przeszukujących dane w poszukiwaniu określonej wartości lub przy zapytaniach dotyczących małego zakresu wartości. Używaj indeksów rowstore z obciążeniami transakcyjnymi, ponieważ zwykle wymagają one głównie wyszukiwania tabel zamiast szerokiego skanowania zakresów tabel.

Wybierz najlepszy indeks magazynu kolumn dla swoich potrzeb

Indeks magazynu kolumn jest klastrowany lub nieklastrowany. Indeks klastrowanego magazynu kolumn może zawierać co najmniej jeden nieklastrowany indeks drzewa B. Indeksy kolumnowe są łatwe do wypróbowania. Jeśli tworzysz tabelę jako indeks columnstore, możesz łatwo przekonwertować tabelę z powrotem na tabelę rowstore, usuwając indeks columnstore.

Poniżej przedstawiono podsumowanie opcji i zaleceń.

Opcja kolumnowego magazynowania danych Zalecenia dotyczące tego, kiedy należy używać Kompresja
sklasteryzowany indeks kolumnowego magazynu danych Użyj dla:

1) Tradycyjne obciążenie magazynu danych ze schematem gwiazdy lub płatka śniegu

2) Obciążenia Internetu rzeczy (IoT), które wstawiają duże ilości danych przy minimalnych aktualizacjach i usuwaniu.		 Średnia 10x
uporządkowany indeks kolumnowy Użyj, gdy klastrowany indeks columnstore jest zapytany za pomocą pojedynczej uporządkowanej kolumny lub zestawu kolumn. Te wskazówki są podobne do wybierania kolumn kluczy dla indeksu klastrowanego rowstore, chociaż skompresowane podstawowe grupy wierszy zachowują się inaczej. Aby uzyskać więcej informacji, zobacz CREATE COLUMNSTORE INDEX i Optymalizacja wydajności z uporządkowanymi indeksami columnstore. Średnia wynosi 10 razy
nieklastrowane indeksy drzewa B na klastrowanym indeksie magazynu kolumn Użyj do:

1. Wymuszanie ograniczeń klucza podstawowego i klucza obcego w klastrowanym indeksie columnstore.

2. Przyspiesz zapytania, które wyszukują określone wartości lub małe zakresy wartości.

3. Przyspieszanie aktualizacji i usuwanie określonych wierszy.		 Średnio dziesięciokrotnie plus nieco dodatkowej przestrzeni do przechowywania dla NCIs.
Indeks kolumnowy nieklastrowany na stosie bazującym na dysku lub indeksie drzewa B Użyj dla:

1) Obciążenie OLTP z pewnymi zapytaniami analitycznymi. Możesz usunąć indeksy drzewa B utworzone na potrzeby analizy i zastąpić je jednym nieklastrowanym indeksem magazynu kolumn.

2) Wiele tradycyjnych obciążeń OLTP, które wykonują operacje Extract, Transform i Load (ETL) w celu przeniesienia danych do oddzielnego magazynu danych. Można wyeliminować proces ETL i oddzielny magazyn danych, tworząc nieklastrowany indeks magazynu kolumn w niektórych tabelach OLTP.		 NCCI to dodatkowy indeks, który wymaga średnio 10% więcej miejsca do magazynowania.
indeks kolumnowy w tabeli w pamięci Takie same zalecenia jak dla nieklastrowanego indeksu kolumnowego w tabeli na dysku, z wyjątkiem, że tabela bazowa jest tabelą w pamięci. Indeks kolumnowy jest indeksem dodatkowym.

Używanie klastrowanego indeksu magazynu kolumn dla dużych tabel magazynu danych

Indeks klastrowanego magazynu kolumn jest większy niż indeks— jest to podstawowy magazyn tabel. Zapewnia wysoką kompresję danych i znaczącą poprawę wydajności zapytań w przypadku dużych tabel faktów magazynowania danych i tabel wymiarów. Klastrowane indeksy magazynu kolumnowego najlepiej nadają się do zapytań analitycznych, a nie zapytań transakcyjnych, ponieważ zapytania analityczne zwykle wykonują operacje na dużych zakresach wartości, zamiast skupiać się na wyszukiwaniu określonych wartości.

Rozważ użycie klastrowanego kolumnowego indeksu magazynującego, gdy:

  • Każda partycja ma co najmniej milion wierszy. Indeksy Columnstore zawierają grupy wierszy w każdej partycji. Jeśli tabela jest zbyt mała, aby wypełnić grupę wierszy w ramach każdej partycji, możesz nie uzyskać korzyści z kompresji magazynu kolumn i wydajności zapytań.
  • Zapytania wykonują przede wszystkim analizę zakresów wartości. Aby na przykład znaleźć średnią wartość kolumny, zapytanie musi przeskanować wszystkie wartości kolumn. Następnie agreguje wartości, sumując je w celu określenia średniej.
  • Większość operacji wstawiania dotyczy dużych ilości danych z minimalnymi aktualizacjami i usunięciami. Wiele obciążeń, takich jak Internet rzeczy (IOT) wstawia duże ilości danych z minimalnymi aktualizacjami i usuwaniem. Te obciążenia mogą czerpać korzyści dzięki zwiększeniu wydajności kompresji i zapytań, które wynikają z użycia klastrowanego indeksu magazynu kolumn.

Nie używaj klastrowanego indeksu magazynu kolumn, gdy:

  • Tabela wymaga typów danych varchar(max), nvarchar(max)lub varbinary(max). Lub zaprojektuj indeks magazynu kolumn, aby nie zawierał tych kolumn (dotyczy: SQL Server 2016 (13.x) i poprzednich wersji).
  • Dane tabeli nie są trwałe. Rozważ użycie kopca lub tabeli tymczasowej, gdy musisz szybko przechowywać i usuwać dane.
  • Tabela zawiera mniej niż milion wierszy na partycję.
  • Ponad 10% operacji w tabeli to aktualizacje i usunięcia. Duża liczba aktualizacji i usuwania powoduje fragmentację. Fragmentacja wpływa na współczynniki kompresji i wydajność zapytań do momentu uruchomienia operacji o nazwie reorganizacja, która przenosi wszystkie dane do magazynu kolumn i usuwa fragmentację. Aby uzyskać więcej informacji, zobacz Minimalizacja fragmentacji indeksu w indeksie kolumnowym.

Aby uzyskać więcej informacji, zobacz Indeksy kolumnowe w hurtowniach danych.

Używanie uporządkowanego indeksu magazynu kolumn dla dużych tabel magazynu danych

Aby uzyskać informacje o dostępności uporządkowanego indeksu columnstore, zobacz Indeksy columnstore: Omówienie.

Rozważ użycie uporządkowanego kolumnowego indeksu magazynowego w następujących scenariuszach:

  • Gdy dane są stosunkowo statyczne (nie podlegają częstym zapisom i usunięciom), a klucz uporządkowanego indeksu magazynu kolumn jest statyczny, uporządkowane indeksy magazynu kolumn mogą zapewnić zdecydowane korzyści wydajnościowe w porównaniu do indeksów magazynu kolumn nieuporządkowanych lub indeksów magazynu wierszy w przypadku obciążeń analitycznych.
  • Im bardziej zróżnicowane wartości w pierwszej kolumnie uporządkowanego indeksu magazynu kolumnowego, tym lepsze mogą być zyski wydajności. Wynika to z ulepszonej eliminacji segmentów dla danych ciągów. Aby uzyskać więcej informacji, zobacz eliminacja segmentów.
  • Wybierz uporządkowany klucz indeksu magazynu kolumn, który jest często używany w zapytaniach i może korzystać z eliminacji segmentów, zwłaszcza pierwsza kolumna klucza. Wzrost wydajności z powodu eliminacji segmentów w innych kolumnach w tabeli jest mniej przewidywalny.
  • Scenariusze użycia, w których należy wykonywać zapytania dotyczące tylko najnowszych danych analitycznych, na przykład ostatnich 15 sekund, mogą skorzystać z uporządkowanych indeksów magazynu kolumn do eliminacji segmentów starszych danych. Pierwsza kolumna w kluczu uporządkowanych danych tabeli kolumnowej musi być typem daty/godziny, na przykład datą/godziną wstawienia lub utworzenia. Eliminacja segmentu byłaby bardziej skuteczna w uporządkowanym indeksie magazynu kolumn niż w nieurządzanym indeksie magazynu kolumn.
  • Rozważ uporządkowane indeksy magazynu kolumn w tabelach zawierających klucze z danymi GUID, gdzie typ danych uniqueidentifier może być teraz używany do eliminacji segmentów .

Uporządkowany indeks kolumnowy może nie być tak skuteczny w następujących scenariuszach:

  • Podobnie jak w przypadku innych indeksów magazynów kolumnowych, wysoki współczynnik operacji wstawiania może spowodować nadmierne obciążenie operacji we/wy pamięci masowej.
  • W przypadku obciążeń, w których występuje dużo operacji zapisu, jakość eliminacji segmentów będzie się z czasem pogarszać z powodu zarządzania grupami wierszy przez moduł przenoszący krotki. Można to złagodzić poprzez regularną konserwację indeksu kolumnowego magazynu danych za pomocą ALTER INDEX REORGANIZE.

Dodaj nieklastrowane indeksy drzewa B w celu wydajnego wyszukiwania w tabelach

Począwszy od programu SQL Server 2016 (13.x), można utworzyć nieklastrowane indeksy B-tree lub rowstore jako indeksy pomocnicze w klastrowanym indeksie magazynu kolumn. Indeks nieklastrowanego drzewa B jest aktualizowany, gdy wprowadzane są zmiany w indeksie magazynu kolumn. Jest to zaawansowana funkcja, której można użyć na swoją korzyść.

Korzystając z pomocniczego indeksu drzewa B, można efektywnie wyszukiwać określone wiersze bez skanowania wszystkich wierszy. Inne opcje również staną się dostępne. Na przykład można wymusić ograniczenie klucza podstawowego lub obcego przy użyciu ograniczenia UNIQUE w indeksie drzewa B. Ponieważ wstawienie nieunikalnej wartości do indeksu drzewa B się nie udaje, SQL Server nie może wstawić wartości do magazynu kolumnowego.

Rozważ użycie indeksu drzewa B w indeksie magazynu kolumn w celu:

  • Uruchamiaj zapytania, które wyszukują określone wartości lub małe zakresy wartości.
  • Wymusza ograniczenie, takie jak ograniczenie klucza podstawowego lub klucza obcego.
  • Wydajne wykonywanie operacji aktualizacji i usuwania. Indeks drzewa B jest w stanie szybko zlokalizować określone wiersze aktualizacji i usunąć bez skanowania pełnej tabeli lub partycji tabeli.
  • Masz dodatkową przestrzeń dyskową do przechowywania indeksu drzewa B.

Używanie nieklastrowanego indeksu magazynu kolumn na potrzeby analizy w czasie rzeczywistym

Od wersji SQL Server 2016 (13.x) można utworzyć nieklastrowany indeks Columnstore na tabeli dyskowej lub w tabeli OLTP przechowywanej w pamięci. Dzięki temu można uruchamiać analizę w czasie rzeczywistym w tabeli transakcyjnej. Podczas gdy transakcje zachodzą w tabeli bazowej, możesz przeprowadzić analizę indeksu kolumnowego. Ponieważ jedna tabela zarządza obydwoma indeksami, zmiany są dostępne w czasie rzeczywistym zarówno dla indeksu wierszowego, jak i indeksu kolumnowego.

Ponieważ indeks magazynu kolumn osiąga 10-krotną lepszą kompresję danych niż indeks magazynu wierszy, wymaga tylko niewielkiej ilości dodatkowego magazynu. Jeśli na przykład skompresowana tabela magazynu wierszy zajmuje 20 GB, indeks magazynu kolumn może wymagać dodatkowego 2 GB. Wymagane dodatkowe miejsce zależy również od liczby kolumn w indeksie magazynu kolumn nieklastrowanych.

Rozważ użycie nieklastrowanego indeksu magazynu kolumn w celu:

  • Wykonywać analizę w czasie rzeczywistym na tabeli z transakcyjnym przechowywaniem wierszy. Istniejące indeksy drzewa B, które są przeznaczone do analizy, można zastąpić nieklastrowanym indeksem kolumnowym.

  • Wyeliminuj potrzebę oddzielnego magazynu danych. Tradycyjnie firmy uruchamiają transakcje w tabeli wierszowej, a następnie ładują dane do oddzielnego magazynu danych w celu przeprowadzenia analizy. W przypadku wielu obciążeń można wyeliminować proces ładowania i oddzielny magazyn danych, tworząc nieklastrowany indeks magazynu kolumn w tabelach transakcyjnych.

Program SQL Server 2016 (13.x) oferuje kilka strategii umożliwiających wykonanie tego scenariusza. Jest to łatwe do wypróbowania, ponieważ można włączyć nieklastrowany indeks magazynu kolumn bez zmian w aplikacji OLTP.

Aby dodać dodatkowe zasoby przetwarzania, możesz uruchomić analizę na czytelnej bazie pomocniczej. Użycie czytelnego zasobu pomocniczego oddziela przetwarzanie zadań transakcyjnych od zadań analitycznych.

Aby uzyskać więcej informacji, zobacz Rozpoczęcie pracy z Columnstore na potrzeby analizy operacyjnej w czasie rzeczywistym

Aby uzyskać więcej informacji na temat wybierania najlepszego indeksu magazynu kolumn, zobacz blog Sunil Agarwal Który indeks magazynu kolumn jest odpowiedni dla mojego obciążenia?.

Używanie partycji tabeli na potrzeby zarządzania danymi i wydajności zapytań

Indeksy kolumnowe obsługują partycjonowanie, co jest skutecznym sposobem zarządzania i archiwizowania danych. Partycjonowanie zwiększa również wydajność zapytań, ograniczając operacje do co najmniej jednej partycji.

Używanie partycji w celu ułatwienia zarządzania danymi

W przypadku dużych tabel jedynym praktycznym sposobem zarządzania zakresami danych jest użycie partycji. Zalety partycji dla tabel typu rowstore mają również zastosowanie do indeksów kolumnowych.

Na przykład zarówno tabele rowstore, jak i columnstore używają partycji do:

  • Kontrolowanie rozmiaru przyrostowych kopii zapasowych. Możesz utworzyć kopię zapasową partycji w celu oddzielenia grup plików, a następnie oznaczyć je jako tylko do odczytu. Dzięki temu przyszłe kopie zapasowe pomijają grupy plików tylko do odczytu.
  • Oszczędzaj koszty magazynowania, przenosząc starszą partycję do tańszego magazynu. Na przykład możesz użyć przełączania partycji, aby przenieść partycję do tańszej lokalizacji magazynu.
  • Wykonywać operacje wydajnie, ograniczając je do partycji. Na przykład można skoncentrować się wyłącznie na pofragmentowanych partycjach w celu konserwacji indeksu.

Ponadto, stosując indeks kolumnowy, korzystasz z partycjonowania do:

  • Oszczędzaj dodatkowe 30% w kosztach magazynowania. Starsze partycje można kompresować przy użyciu opcji kompresji COLUMNSTORE_ARCHIVE. Wydajność zapytań może być niższa, co może być akceptowalne, jeśli partycja jest rzadko zapytywana.

Zwiększanie wydajności zapytań przy użyciu partycji

Korzystając z partycji, można ograniczyć zapytania do skanowania tylko określonych partycji, co ogranicza liczbę wierszy do skanowania. Jeśli na przykład indeks jest partycjonowany według roku, a zapytanie analizuje dane z ostatniego roku, musi skanować dane tylko w jednej partycji.

Używanie mniejszej liczby partycji dla indeksu składowania kolumn

Jeśli nie masz wystarczająco dużego rozmiaru danych, indeks magazynu kolumn działa najlepiej z mniejszą liczbą partycji niż to, czego można użyć dla indeksu magazynu wierszy. Jeśli nie masz co najmniej miliona wierszy na partycję, większość wierszy może trafić do magazynu delta, gdzie nie uzyskują korzyści z wydajności, jakie daje kompresja kolumnowa. Jeśli na przykład załadujesz milion wierszy do tabeli z 10 partycjami, a każda partycja otrzyma 100 000 wierszy, wszystkie wiersze przechodzą do grup wierszy różnicowych.

Przykład:

  • Załaduj 1000 000 wierszy do jednej partycji lub tabeli bez partycji. Otrzymujesz jedną skompresowaną grupę wierszy z 1000 000 wierszy. Jest to doskonałe rozwiązanie w przypadku wysokiej kompresji danych i szybkiej wydajności zapytań.
  • Załaduj 1000 000 wierszy równomiernie do 10 partycji. Każda partycja otrzymuje 100 000 wierszy, co jest mniej niż minimalny próg kompresji kolumnowego magazynu danych. W rezultacie indeks columnstore może mieć 10 grup wierszy delta, zawierająca po 100 000 wierszy każda. Istnieją sposoby na wymuszenie grup wierszy delta do magazynu kolumnowego. Jeśli jednak są to jedyne wiersze w indeksie magazynu kolumn, skompresowane grupy wierszy są zbyt małe, aby uzyskać najlepszą kompresję i wydajność zapytań.

Aby uzyskać więcej informacji na temat partycjonowania, zobacz wpis Sunila Agarwala na blogu, Czy należy partycjonować indeks kolumnowy?.

Wybieranie odpowiedniej metody kompresji danych

Indeks magazynu kolumn oferuje dwie opcje kompresji danych: kompresja magazynu kolumn i kompresja archiwum. Możesz wybrać opcję kompresji podczas tworzenia indeksu lub zmienić ją później przy użyciu ALTER INDEX ... ODTWÓRZ.

Używanie kompresji magazynu kolumn w celu uzyskania najlepszej wydajności zapytań

Kompresja indeksów kolumnowych zwykle osiąga 10-krotnie lepszy stopień kompresji w porównaniu z indeksami wierszowymi. Jest to standardowa metoda kompresji indeksów magazynu kolumn i umożliwia szybką wydajność zapytań.

Użyj kompresji archiwum, aby uzyskać najlepszą kompresję danych

Kompresja archiwum jest przeznaczona do maksymalnej kompresji, gdy wydajność zapytań nie jest tak ważna. Osiąga wyższe współczynniki kompresji danych niż kompresja typu columnstore, ale wiąże się to z kosztami. Kompresowanie i dekompresowanie danych trwa dłużej, więc nie nadaje się do szybkiej wydajności zapytań.

Używaj optymalizacji podczas konwertowania tabeli rowstore na indeks columnstore

Jeśli dane znajdują się już w tabeli wierszowej, możesz użyć CREATE COLUMNSTORE INDEX, aby przekonwertować ją na indeks kolumnowy. Istnieje kilka optymalizacji, które poprawią wydajność zapytań po przekonwertowaniu tabeli, opisane w dalszej części.

Popraw jakość grupy wierszy, używając ustawienia MAXDOP

Można skonfigurować maksymalną liczbę procesorów do konwersji indeksu typu sterta lub klastrowanego drzewa B na indeks magazynu kolumnowego. Aby skonfigurować procesory, użyj maksymalnego stopnia równoległości (MAXDOP).

Jeśli masz duże ilości danych, MAXDOP 1 może być zbyt wolny. Zwiększenie wartości MAXDOP do 4 działa prawidłowo. Jeśli spowoduje to kilka grup wierszy, które nie mają optymalnej liczby wierszy, można uruchomić ALTER INDEX REORGANIZE, aby scalić je razem w tle.

Zachowaj posortowaną kolejność indeksu drzewa typu B

Ponieważ indeks drzewa B przechowuje już wiersze w posortowanej kolejności, zachowanie tej kolejności po skompresowaniu wierszy do indeksu magazynu kolumn może poprawić wydajność zapytań.

Indeks magazynu kolumn nie sortuje danych, ale używa metadanych do śledzenia minimalnych i maksymalnych wartości poszczególnych segmentów kolumn w każdej grupie wierszy. Podczas skanowania pod kątem zakresu wartości można szybko obliczyć, kiedy pominąć grupę wierszy. Gdy dane są uporządkowane, można pominąć więcej grup wierszy.

Aby zachować kolejność sortowania podczas konwersji:

  • Użyj CREATE COLUMNSTORE INDEX z klauzulą DROP_EXISTING. Spowoduje to również zachowanie nazwy indeksu. Jeśli masz skrypty, które już używają nazwy indeksu typu rowstore, nie musisz ich aktualizować.

    W tym przykładzie indeks klastrowanego magazynu wierszy na tabeli o nazwie MyFactTable jest konwertowany do klastrowanego indeksu magazynu kolumn. Nazwa indeksu ClusteredIndex_d473567f7ea04d7aafcac5364c241e09pozostaje taka sama.

    CREATE CLUSTERED COLUMNSTORE INDEX ClusteredIndex_d473567f7ea04d7aafcac5364c241e09
ON MyFactTable
WITH (DROP_EXISTING = ON);

Omówienie eliminacji segmentów

Każda grupa wierszy zawiera jeden segment kolumn dla każdej kolumny w tabeli. Każdy segment kolumny jest kompresowany razem i przechowywany na nośniku fizycznym.

Istnieją metadane z każdym segmentem, aby umożliwić szybką eliminację segmentów bez ich odczytywania. 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 kolumnowym. Aby uzyskać więcej informacji, zobacz eliminacja segmentu.

Są to zadania służące do tworzenia i zarządzania indeksami magazynów kolumnowych.

Zadanie Artykuły referencyjne Notatki
Utwórz tabelę jako magazyn kolumn. CREATE TABLE (Transact-SQL) Począwszy od programu SQL Server 2016 (13.x), możesz utworzyć tabelę jako indeks klastrowanego magazynu kolumn. Nie musisz najpierw tworzyć tabeli wierszowej, a potem konwertować jej na tabelę kolumnową.
Utwórz tabelę w pamięci z indeksem columnstore. CREATE TABLE (Transact-SQL) Począwszy od programu SQL Server 2016 (13.x), można utworzyć tabelę zoptymalizowaną pod kątem pamięci z indeksem magazynu kolumn. Indeks kolumnowy można również dodać po utworzeniu tabeli, korzystając ze składni ALTER TABLE ADD INDEX.
Przekonwertuj tabelę typu rowstore na tabelę typu columnstore. CREATE COLUMNSTORE INDEX (Transact-SQL) Przekonwertuj istniejącą stertę lub drzewo B na magazyn kolumn. Przykłady pokazują, jak obsługiwać istniejące indeksy, a także nazwę indeksu podczas przeprowadzania tej konwersji.
Przekształcić tabelę kolumnową na tabelę wierszową. CREATE CLUSTERED INDEX (Transact-SQL) lub Konwertuj tabelę kolumn ponownie na stertę wierszy Zazwyczaj ta konwersja nie jest konieczna, ale czasami może wystąpić potrzeba konwersji. Przykłady pokazują, jak przekonwertować magazyn kolumn na stertę lub indeks klastrowany.
Utwórz indeks columnstore w tabeli rowstore. CREATE COLUMNSTORE INDEX (Transact-SQL) Tabela magazynująca wiersze może mieć jeden indeks magazynu kolumn. Począwszy od programu SQL Server 2016 (13.x), indeks magazynu kolumn może mieć warunek filtrowany. Przykłady pokazują podstawową składnię.
Tworzenie wydajnych indeksów na potrzeby analizy operacyjnej. Rozpocznij pracę z Columnstore do analizy operacyjnej w czasie rzeczywistym Opisuje sposób tworzenia uzupełniających indeksów magazynu kolumn i indeksów drzewa B, tak aby zapytania OLTP używały indeksów drzewa B, a zapytania analityczne indeksów magazynu kolumn.
Twórz wydajne indeksy kolumnowe na potrzeby magazynów danych. Indeksy kolumnowe w magazynie danych Opisuje sposób używania indeksów B-tree w tabelach magazynu kolumn do tworzenia wydajnych zapytań dotyczących magazynowania danych.
Użyj indeksu drzewa B, aby wymusić ograniczenie klucza podstawowego w indeksie kolumnowym. Indeksy kolumnowe w magazynie danych Przedstawia sposób łączenia indeksów drzewa B i indeksów kolumnowych w celu wymuszania ograniczeń klucza podstawowego na indeksie kolumnowym.
Usuń indeks kolumnowy UPUŚĆ INDEKS (Transact-SQL) Usuwanie indeksu magazynu kolumn używa standardowej składni DROP INDEX używanej przez indeksy B-tree. Usuwanie klastrowanego indeksu magazynu kolumn konwertuje tabelę magazynu kolumn na stertę.
Usuń wiersz z indeksu columnstore DELETE (Transact-SQL) Użyj DELETE (Transact-SQL), aby usunąć wiersz.

wiersz magazynu kolumnowego: SQL Server oznacza wiersz jako logicznie usunięty, ale nie zwraca pamięci fizycznej dla wiersza do czasu odbudowy indeksu.

deltastore wiersz: SQL Server logicznie i fizycznie usuwa wiersz.
Zaktualizuj wiersz w indeksie kolumnowym UPDATE (Transact-SQL) Użyj UPDATE (Transact-SQL), aby zaktualizować wiersz.

Wiersz magazynu kolumnowego: program SQL Server oznacza wiersz jako logicznie usunięty, a następnie wstawia zaktualizowany wiersz do deltastore.

deltastore: SQL Server aktualizuje wiersz w deltastore.
Wymuś przeniesienie wszystkich wierszy z „magazynu delty” do „magazynu kolumnowego”. ALTER INDEX (Transact-SQL) ... ODBUDOWAĆ

Optymalizowanie konserwacji indeksu w celu zwiększenia wydajności zapytań i zmniejszenia zużycia zasobów		 ALTER INDEX z opcją REBUILD wymusza zapis wszystkich wierszy w magazynie danych kolumnowych.
Defragmentacja indeksu magazynu kolumn ALTER INDEX (Transact-SQL) ALTER INDEX ... REORGANIZE defragmentuje indeksy kolumnowe w trybie online.
Połącz tabele z indeksami kolumnowymi. MERGE (Transact-SQL)

Powiązana zawartość

Aby utworzyć pusty indeks kolumnowy dla:

Aby uzyskać więcej informacji na temat konwertowania istniejącego stosu magazynu wierszy lub indeksu drzewa B na indeks klastrowanego magazynu kolumn lub tworzenia indeksu magazynu kolumn nieklastrowanego, zobacz CREATE COLUMNSTORE INDEX (Transact-SQL).