Indexy v tabulkách ve vyhrazeném fondu SQL v Azure Synapse Analytics

Doporučení a příklady indexování tabulek ve vyhrazeném fondu SQL ve službě Azure Synapse Analytics

Typy indexů

Vyhrazený SQL fond nabízí několik možností indexování, mezi které patří clusterované columnstore indexy, clusterované indexy a neklasterové indexy a možnost neindexování označovaná také jako halda.

Chcete-li vytvořit tabulku s indexem, podívejte se na dokumentaci k CREATE TABLE (vyhrazený fond SQL).

Clusterované sloupcové indexy

Ve výchozím nastavení vyhrazený fond SQL vytvoří clusterovaný index columnstore, pokud nejsou v tabulce zadány žádné možnosti indexu. Clusterované tabulky columnstore nabízejí nejvyšší úroveň komprese dat i nejlepší celkový výkon dotazů. Tabulky s clusterovaným columnstore indexem bývají obecně výkonnější než tabulky s clusterovaným indexem nebo haldou a obvykle jsou nejlepší volbou pro velké tabulky. Z těchto důvodů je clusterovaný columnstore nejlepším místem, kde začít, když si nejste jisti, jak indexovat tabulku.

Pokud chcete vytvořit tabulku clusterovaného columnstore, zadejte CLUSTERED COLUMNSTORE INDEX v klauzuli WITH nebo ponechte klauzuli WITH vypnutou:

CREATE TABLE myTable
  (  
    id int NOT NULL,  
    lastName varchar(20),  
    zipCode varchar(6)  
  )  
WITH ( CLUSTERED COLUMNSTORE INDEX );

Existuje několik scénářů, kdy clusterované columnstore nemusí být dobrou volbou:

• Tabulky Columnstore nepodporují varchar(max), nvarchar(max) a varbinary(max). Zvažte použití haldy nebo klastrovaného indexu místo toho.
• Tabulky columnstore můžou být pro přechodná data méně efektivní. Zvažte haldu a dočasné tabulky.
• Malé tabulky s méně než 60 miliony řádků Zvažte tabulky haldy.

Tabulky haldy

Když dočasně ukládáte data ve vyhrazeném fondu SQL, můžete zjistit, že použití haldy (heap) tabulky zrychluje celkový proces. Důvodem je, že načítání do hromad je rychlejší než do indexových tabulek a v některých případech může následné čtení probíhat z mezipaměti. Pokud načítáte data pouze pro přípravu před spuštěním dalších transformací, je načtení do haldy mnohem rychlejší než načtení dat do clusterové tabulky columnstore. Načítání dat do dočasné tabulky navíc načítá rychleji než načítání tabulky do trvalého úložiště. Po načtení dat můžete v tabulce vytvořit indexy pro rychlejší výkon dotazů.

Tabulky columnstore clusteru začínají dosahovat optimální komprese, jakmile bude více než 60 milionů řádků. U malých vyhledávacích tabulek, méně než 60 milionů řádků, zvažte použití HEAP nebo clusterovaného indexu pro rychlejší výkon dotazů.

Pokud chcete vytvořit tabulku typu HEAP, zadejte HEAP v klauzuli WITH:

CREATE TABLE myTable
  (  
    id int NOT NULL,  
    lastName varchar(20),  
    zipCode varchar(6)  
  )  
WITH ( HEAP );

Poznámka:

Pokud často provádíte operace INSERT, UPDATE nebo DELETE na tabulce haldy, doporučujeme zahrnout opětovné sestavení tabulky do plánu údržby pomocí příkazu ALTER TABLE. Například ALTER TABLE [SchemaName].[TableName] REBUILD. Tento postup přispívá ke snížení fragmentace, což vede ke zlepšení výkonu při operacích čtení.

Clusterované a neclusterované indexy

Clusterované indexy mohou být výkonnější než clusterované tabulky s columnstore, když je potřeba rychle načíst jediný řádek. U dotazů, ve kterých se vyžaduje vyhledávání s jedním nebo velmi malým množstvím řádků s extrémní rychlostí, zvažte clusterovaný index nebo neclusterovaný sekundární index. Nevýhodou použití clusterovaného indexu je, že pouze dotazy, které mají výhodu, jsou ty, které používají vysoce selektivní filtr ve sloupci clusterovaného indexu. Pokud chcete zlepšit filtrování u jiných sloupců, můžete do jiných sloupců přidat neclusterovaný index. Avšak každý index, který je přidán do tabulky, zvyšuje nároky na prostor a čas zpracování při načítání.

Pokud chcete vytvořit tabulku clusterovaného indexu, v klauzuli WITH zadejte CLUSTERED INDEX:

CREATE TABLE myTable
  (  
    id int NOT NULL,  
    lastName varchar(20),  
    zipCode varchar(6)  
  )  
WITH ( CLUSTERED INDEX (id) );

Pokud chcete do tabulky přidat neclusterovaný index, použijte následující syntaxi:

CREATE INDEX zipCodeIndex ON myTable (zipCode);

Optimalizace clusterovaných columnstore indexů

Clusterované tabulky columnstore uspořádají data do segmentů. Pro zajištění optimálního výkonu dotazů na tabulce s úložištěm sloupců je zásadní mít vysokou kvalitu segmentů. Kvalitu segmentů je možné změřit podle počtu řádků v komprimované skupině řádků. Kvalita segmentu je nejlepší, pokud je alespoň 100 tisíc řádků na komprimovanou skupinu řádků a výkon se zlepší, když se počet řádků na skupinu řádků blíží 1 048 576 řádků, což je maximální počet řádků, které může skupina řádků obsahovat.

Následující zobrazení můžete vytvořit a použít ve vašem systému k výpočtu průměrných řádků na skupinu řádků a identifikaci všech neoptimálních indexů columnstore clusteru. Poslední sloupec v tomto zobrazení vygeneruje příkaz SQL, který lze použít k opětovnému sestavení indexů.

CREATE VIEW dbo.vColumnstoreDensity
AS
SELECT
        GETDATE()                                                               AS [execution_date]
,       DB_Name()                                                               AS [database_name]
,       s.name                                                                  AS [schema_name]
,       t.name                                                                  AS [table_name]
,       MAX(p.partition_number)                                                 AS [table_partition_count]
,       SUM(rg.[total_rows])                                                    AS [row_count_total]
,       SUM(rg.[total_rows])/COUNT(DISTINCT rg.[distribution_id])               AS [row_count_per_distribution_MAX]
,       CEILING((SUM(rg.[total_rows])*1.0/COUNT(DISTINCT rg.[distribution_id]))/1048576) AS [rowgroup_per_distribution_MAX]
,       SUM(CASE WHEN rg.[State] = 0 THEN 1                   ELSE 0    END)    AS [INVISIBLE_rowgroup_count]
,       SUM(CASE WHEN rg.[State] = 0 THEN rg.[total_rows]     ELSE 0    END)    AS [INVISIBLE_rowgroup_rows]
,       MIN(CASE WHEN rg.[State] = 0 THEN rg.[total_rows]     ELSE NULL END)    AS [INVISIBLE_rowgroup_rows_MIN]
,       MAX(CASE WHEN rg.[State] = 0 THEN rg.[total_rows]     ELSE NULL END)    AS [INVISIBLE_rowgroup_rows_MAX]
,       AVG(CASE WHEN rg.[State] = 0 THEN rg.[total_rows]     ELSE NULL END)    AS [INVISIBLE_rowgroup_rows_AVG]
,       SUM(CASE WHEN rg.[State] = 1 THEN 1                   ELSE 0    END)    AS [OPEN_rowgroup_count]
,       SUM(CASE WHEN rg.[State] = 1 THEN rg.[total_rows]     ELSE 0    END)    AS [OPEN_rowgroup_rows]
,       MIN(CASE WHEN rg.[State] = 1 THEN rg.[total_rows]     ELSE NULL END)    AS [OPEN_rowgroup_rows_MIN]
,       MAX(CASE WHEN rg.[State] = 1 THEN rg.[total_rows]     ELSE NULL END)    AS [OPEN_rowgroup_rows_MAX]
,       AVG(CASE WHEN rg.[State] = 1 THEN rg.[total_rows]     ELSE NULL END)    AS [OPEN_rowgroup_rows_AVG]
,       SUM(CASE WHEN rg.[State] = 2 THEN 1                   ELSE 0    END)    AS [CLOSED_rowgroup_count]
,       SUM(CASE WHEN rg.[State] = 2 THEN rg.[total_rows]     ELSE 0    END)    AS [CLOSED_rowgroup_rows]
,       MIN(CASE WHEN rg.[State] = 2 THEN rg.[total_rows]     ELSE NULL END)    AS [CLOSED_rowgroup_rows_MIN]
,       MAX(CASE WHEN rg.[State] = 2 THEN rg.[total_rows]     ELSE NULL END)    AS [CLOSED_rowgroup_rows_MAX]
,       AVG(CASE WHEN rg.[State] = 2 THEN rg.[total_rows]     ELSE NULL END)    AS [CLOSED_rowgroup_rows_AVG]
,       SUM(CASE WHEN rg.[State] = 3 THEN 1                   ELSE 0    END)    AS [COMPRESSED_rowgroup_count]
,       SUM(CASE WHEN rg.[State] = 3 THEN rg.[total_rows]     ELSE 0    END)    AS [COMPRESSED_rowgroup_rows]
,       SUM(CASE WHEN rg.[State] = 3 THEN rg.[deleted_rows]   ELSE 0    END)    AS [COMPRESSED_rowgroup_rows_DELETED]
,       MIN(CASE WHEN rg.[State] = 3 THEN rg.[total_rows]     ELSE NULL END)    AS [COMPRESSED_rowgroup_rows_MIN]
,       MAX(CASE WHEN rg.[State] = 3 THEN rg.[total_rows]     ELSE NULL END)    AS [COMPRESSED_rowgroup_rows_MAX]
,       AVG(CASE WHEN rg.[State] = 3 THEN rg.[total_rows]     ELSE NULL END)    AS [COMPRESSED_rowgroup_rows_AVG]
,       'ALTER INDEX ALL ON ' + s.name + '.' + t.NAME + ' REBUILD;'             AS [Rebuild_Index_SQL]
FROM    sys.[dm_pdw_nodes_db_column_store_row_group_physical_stats] rg
JOIN    sys.[pdw_nodes_tables] nt                   ON  rg.[object_id]          = nt.[object_id]
                                                    AND rg.[pdw_node_id]        = nt.[pdw_node_id]
                                                    AND rg.[distribution_id]    = nt.[distribution_id]
JOIN    sys.[pdw_permanent_table_mappings] mp                 ON  nt.[name]               = mp.[physical_name]
JOIN    sys.[tables] t                              ON  mp.[object_id]  = t.[object_id]
JOIN    sys.[schemas] s                             ON t.[schema_id]    = s.[schema_id]
JOIN    sys.[partitions] p                          ON P.object_id      = t.object_id
GROUP BY
        s.[name]
,       t.[name];

Teď, když jste vytvořili zobrazení, spusťte tento dotaz a identifikujte tabulky se skupinami řádků s méně než 100 K řádky. Pokud hledáte optimální kvalitu segmentu, můžete zvýšit prahovou hodnotu 100 K.

SELECT    *
FROM    [dbo].[vColumnstoreDensity]
WHERE    COMPRESSED_rowgroup_rows_AVG < 100000
        OR INVISIBLE_rowgroup_rows_AVG < 100000;

Po spuštění dotazu můžete začít prohlížet data a analyzovat výsledky. Tato tabulka vysvětluje, na co se zaměřit v analýze skupin řádků.

Sloupec	Jak používat tato data
[table_partition_count]	Pokud je tabulka rozdělená na oddíly, můžete očekávat, že se zobrazí vyšší počty skupin řádků Open. Každý oddíl v distribuci by teoreticky mohl mít přidruženou otevřenou skupinu řádků. Zahrňte to do své analýzy. Malá tabulka, která byla rozdělena, by mohla být optimalizována odebráním dělení úplně, protože by se tím zlepšila komprese.
[row_count_total]	Celkový počet řádků pro tabulku. Tuto hodnotu můžete například použít k výpočtu procenta řádků v komprimovaném stavu.
[row_count_per_distribution_MAX]	Pokud jsou všechny řádky rovnoměrně rozdělené, bude to cílový počet řádků na rozdělení. Porovnejte tuto hodnotu s compressed_rowgroup_count.
[COMPRESSED_rowgroup_rows]	Celkový počet řádků v tabulce ve formátu sloupcového úložiště
[COMPRESSED_rowgroup_rows_AVG]	Pokud je průměrný počet řádků výrazně menší než maximální počet řádků pro skupinu řádků, zvažte použití funkce CTAS nebo ALTER INDEX REBUILD k rekomprimování dat.
[COMPRESSED_rowgroup_count]	Počet skupin řádků ve formátu columnstore Pokud je toto číslo vzhledem k tabulce velmi vysoké, je to indikátor, že hustota columnstore je nízká.
[KOMPRESOVANÉ_skupina_řádky_ODSTRANĚNO]	Řádky jsou logicky odstraněny ve formátu columnstore. Pokud je číslo vysoké vzhledem k velikosti tabulky, zvažte znovuvytvoření oddílu nebo obnovení indexu, což je fyzicky odstraní.
[COMPRESSED_rowgroup_rows_MIN]	Použijte to se sloupci AVG a MAX, abyste porozuměli rozsahu hodnot pro skupiny řádků ve vašem columnstore. Nízké číslo pod prahovou hodnotou zatížení (102 400 na jednotkovém zarovnaném rozložení) naznačuje, že jsou možné optimalizace při zatížení dat.
[COMPRESSED_rowgroup_rows_MAX]	Viz výše
[OPEN_rowgroup_count]	Otevřené skupiny řádků jsou normální. Jedna by přiměřeně očekávala jednu skupinu řádků OPEN na distribuci tabulky (60). Nadměrné počty naznačují načítání dat napříč oddíly. Pečlivě zkontrolujte strategii dělení, abyste měli jistotu, že je správná.
[OPEN_rowgroup_rows]	Každá skupina řádků může mít maximálně 1 048 576 řádků. Pomocí této hodnoty zjistíte, jak jsou v současné době úplné skupiny otevřených řádků.
[OPEN_rowgroup_rows_MIN]	Otevřené skupiny naznačují, že data se buď postupně načítají do tabulky, nebo že se předchozí načtení přelilo přes zbývající řádky do této skupiny řádků. Pomocí sloupců MIN, MAX a AVG můžete zjistit, kolik dat se nachází ve skupinách řádků OPEN. U menších tabulek to může být až 100 % všech dat. Při této situaci použijte ALTER INDEX REBUILD k přenesení dat do columnstore.
[OPEN_rowgroup_rows_MAX]	Viz výše
[OPEN_rowgroup_rows_AVG]	Viz výše
[UZAVŘENÝ_skupina_řádků]	Podívejte se na zavřenou skupinu řádků pro kontrolu.
[UZAVŘENÁ_skupina_řádků_počet]	Počet uzavřených skupin řádků by měl být nízký, pokud se vůbec nějaké zobrazí. Uzavřené skupiny řádků lze převést na komprimované skupiny řádků pomocí ALTER INDEX ... Příkaz REORGANIZE. Obvykle se to ale nevyžaduje. Uzavřené skupiny se automaticky převedou na columnstore skupiny řádků procesem přesunu dvojic na pozadí.
[UZAVŘENO_skupinové_řádky_MIN]	Skupiny uzavřených řádků by měly mít velmi vysokou míru naplnění. Pokud je míra výplně pro uzavřenou skupinu řádků nízká, je potřeba provést další analýzu columnstore.
[CLOSED_rowgroup_rows_MAX]	Viz výše
[CLOSED_rowgroup_rows_AVG]	Viz výše
[Rebuild_Index_SQL]	SQL pro opětovné sestavení indexu columnstore pro tabulku

Dopad údržby indexů

Sloupec Rebuild_Index_SQL v vColumnstoreDensity zobrazení obsahuje ALTER INDEX REBUILD příkaz, který lze použít k opětovnému sestavení indexů. Při opětovném sestavení indexů nezapomeňte přidělit dostatek paměti relaci, která znovu sestaví index. Chcete-li to provést, zvyšte třídu prostředků uživatele, který má oprávnění k opětovnému sestavení indexu v této tabulce na doporučené minimum. Příklad najdete v tématu Opětovné sestavení indexů pro zlepšení kvality segmentů dále v tomto článku.

U tabulky s uspořádaným clusterovaným columnstore indexem ALTER INDEX REBUILD se data znovu seřadí pomocí tempdb. Monitorování databáze tempdb během operací opětovného sestavení Pokud potřebujete více místa v tempdb, rozšiřte kapacitu databázového fondu. Po dokončení opětovného sestavení indexu snížit zpět rozsah.

U tabulky s uspořádaným clusterovaným columnstore indexem ALTER INDEX REORGANIZE se data neřadí znovu. Chcete-li data znovu seřadit, použijte ALTER INDEX REBUILD.

Další informace o seřazených clusterovaných columnstore indexech najdete v tématu Ladění výkonu pomocí seřazeného clusterovaného columnstore indexu.

Příčiny špatné kvality indexů columnstore

Pokud jste identifikovali tabulky s nízkou kvalitou segmentů, chcete identifikovat původní příčinu. Níže jsou uvedeny některé další běžné příčiny špatné kvality segmentů:

1. Zatížení paměti při vytváření indexu
2. Velký objem operací DML
3. Malé nebo mírné operace zatížení
4. Příliš mnoho oddílů

Tyto faktory můžou způsobit, že index columnstore bude mít výrazně méně než optimálních 1 milion řádků na skupinu řádků. Můžou také způsobit, že řádky přejdou do skupiny delta řádků místo komprimované skupiny řádků.

Poznámka:

Tabulky ve sloupcovém úložišti obvykle neodesílají data do komprimovaného segmentu, dokud v tabulce není více než 1 milionu řádků. Pokud má tabulka s clusterovaným indexem columnstore mnoho otevřených skupin řádků s celkovým počtem řádků, které nesplňují prahovou hodnotu pro kompresi (1 milion řádků), zůstanou tyto skupiny řádků otevřené a uloží se jako data řádků. V důsledku toho se tím zvětší velikost distribuční databáze, protože nejsou komprimované. Kromě toho tyto otevřené skupiny řádků nebudou těžit z CCI a budou vyžadovat více prostředků pro údržbu. Může být vhodné použít ALTER INDEX REORGANIZE.

Zatížení paměti při vytváření indexu

Počet řádků na komprimovanou skupinu řádků přímo souvisí s šířkou řádku a množstvím paměti dostupné ke zpracování skupiny řádků. Když se řádky zapisují do tabulek columnstore při zatížení paměti, může tím utrpět kvalita segmentů columnstore. Osvědčeným postupem je proto dát relaci, která zapisuje do tabulek indexu columnstore, přístup k co nejvíce paměti. Vzhledem k tomu, že existuje kompromis mezi pamětí a souběžností, pokyny ke správnému přidělení paměti závisí na datech v jednotlivých řádcích tabulky, jednotkách datového skladu přidělených vašemu systému a počtu slotů souběžnosti, které můžete dát relaci, která zapisuje data do tabulky.

Velký objem operací DML

Velký objem operací DML, které aktualizují a odstraní řádky, můžou do columnstore zavádět neefektivitu. To platí zejména v případě, že je změněna většina z těchto řádků ve skupině řádků.

• Odstranění řádku z komprimované skupiny řádků pouze logicky označí řádek jako odstraněný. Řádek zůstane ve skupině komprimovaných řádků, dokud se oddíl nebo tabulka znovu nesestaví.
• Když vložíte řádek, přidá se řádek do interní tabulky rowstore označované jako delta row group. Vložený řádek se nepřevede na columnstore, dokud se skupina řádků delta nezaplní a neoznačí se jako uzavřená. Skupiny řádků se zavře, jakmile dosáhnou maximální kapacity 1 048 576 řádků.
• Aktualizace řádku ve formátu columnstore se zpracuje jako logické odstranění a pak vložení. Vložený řádek může být uložen v rozdílovém úložišti.

Operace dávkové aktualizace a vkládání, které překračují hromadnou prahovou hodnotu 102 400 řádků na distribuci zarovnanou do oddílů, směřují přímo do formátu columnstore. Za předpokladu rovnoměrného rozdělení byste ale museli upravit více než 6,144 milionů řádků v jedné operaci, aby k tomu došlo. Pokud je počet řádků pro dané rozdělení zarovnané do oddílů menší než 102 400, řádky přejdou do rozdílového úložiště a zůstanou tam, dokud nebudou vloženy nebo změněny dostatečné řádky pro zavření skupiny řádků nebo opětovného vytvoření indexu.

Malé nebo průběžné zatěžovací procesy

Malá zatížení, která proudí do vyhrazeného fondu SQL, se také někdy označují jako malá zatížení. Obvykle představují téměř konstantní datový proud, který systém ingestuje. Vzhledem k tomu, že tento datový proud je téměř souvislý, není objem řádků zvláště velký. Častěji než ne data jsou výrazně nižší než prahová hodnota požadovaná pro přímé načtení do formátu columnstore.

V těchto situacích je často lepší nejprve umístit data do blob storage v Azure a nechat je nahromadit před načtením. Tato technika se často označuje jako mikrodávkové dávkování.

Příliš mnoho oddílů

Další věcí, kterou je potřeba vzít v úvahu, je dopad dělení na clusterované tabulky columnstore. Než dojde k rozdělení, vyhrazený SQL fond již rozdělí vaše data do 60 databází. Dělením dále rozdělíte data. Pokud rozdělíte data, zvažte, že každý oddíl potřebuje alespoň 1 milion řádků, aby mohl využívat clusterovaný index columnstore. Pokud tabulku rozdělíte na 100 oddílů, potřebuje vaše tabulka alespoň 6 miliard řádků, aby využívala clusterovaný index columnstore (60 distribucí 100 oddílů 1 milion řádků). Pokud tabulka o stovce oddílů nemá 6 miliard řádků, snižte počet oddílů nebo zvažte místo toho použití heapové tabulky.

Po načtení tabulek s některými daty pomocí následujících kroků identifikujte a znovu sestavte tabulky s podoptimálními clusterovanými indexy columnstore.

Opětovné sestavení indexů za účelem zlepšení kvality segmentů

Krok 1: Identifikace nebo vytvoření uživatele, který používá správnou třídu prostředků

Jedním z rychlých způsobů, jak okamžitě zlepšit kvalitu segmentu, je opětovné sestavení indexu. Kód SQL vrácený výše uvedeným zobrazením obsahuje příkaz ALTER INDEX REBUILD, který lze použít k opětovnému sestavení vašich indexů. Při opětovném sestavení vašich indexů nezapomeňte přidělit dostatek paměti relaci, která je znovu sestaví. Chcete-li to provést, zvyšte třídu prostředků uživatele, který má oprávnění k opětovnému sestavení indexu v této tabulce na doporučené minimum.

Níže je příklad, jak uživateli přidělit disponibilní paměť zvýšením jeho zdrojové třídy. Pokud chcete pracovat s třídami prostředků, přečtěte si téma Třídy prostředků pro správu úloh.

EXEC sp_addrolemember 'xlargerc', 'LoadUser';

Krok 2: Opětovné sestavení clusterovaných indexů columnstore s využitím uživatele vyšší třídy prostředků

Přihlaste se jako uživatel z kroku 1 (LoadUser), který teď používá vyšší třídu prostředků, a spusťte příkazy ALTER INDEX. Ujistěte se, že tento uživatel má oprávnění ALTER k tabulkám, ve kterých se index znovu sestavuje. Tyto příklady ukazují, jak znovu sestavit celý index columnstore nebo případně jak znovu sestavit jeden oddíl. U velkých tabulek je vhodnější znovu sestavit indexy jednoho oddílu najednou.

Případně místo opětovného sestavení indexu můžete tabulku zkopírovat do nové tabulky pomocí CTAS. Jaký způsob je nejlepší? U velkých objemů dat je CTAS obvykle rychlejší než ALTER INDEX. U menších objemů dat je funkce ALTER INDEX jednodušší a nevyžaduje prohození tabulky.

-- Rebuild the entire clustered index
ALTER INDEX ALL ON [dbo].[DimProduct] REBUILD;

-- Rebuild a single partition
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5;

-- Rebuild a single partition with archival compression
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5 WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);

-- Rebuild a single partition with columnstore compression
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5 WITH (DATA_COMPRESSION = COLUMNSTORE);

Opětovné sestavení indexu ve vyhrazeném fondu SQL je offline operace. Další informace o opětovném sestavení indexů naleznete v části ALTER INDEX REBUILD v Columnstore Indexy Defragmentace a ALTER INDEX.

Krok 3: Ověření zvýšení kvality clusterovaného segmentu columnstore

Znovu spusťte dotaz, který identifikoval tabulku s nízkou kvalitou segmentu, a ověřte, že se zlepšila kvalita segmentu. Pokud se kvalita segmentu nezlepší, může to být způsobeno tím, že řádky v tabulce jsou příliš široké. Při opětovném sestavení indexů zvažte použití vyšší třídy prostředků nebo DWU.

Opětovné sestavení indexů pomocí CTAS a přepínání oddílů

Tento příklad používá příkaz CREATE TABLE AS SELECT (CTAS) a přepínání oddílů k opětovnému sestavení oddílu tabulky.

-- Step 1: Select the partition of data and write it out to a new table using CTAS
CREATE TABLE [dbo].[FactInternetSales_20000101_20010101]
    WITH    (   DISTRIBUTION = HASH([ProductKey])
            ,   CLUSTERED COLUMNSTORE INDEX
            ,   PARTITION   (   [OrderDateKey] RANGE RIGHT FOR VALUES
                                (20000101,20010101
                                )
                            )
            )
AS
SELECT  *
FROM    [dbo].[FactInternetSales]
WHERE   [OrderDateKey] >= 20000101
AND     [OrderDateKey] <  20010101
;

-- Step 2: Switch IN the rebuilt data with TRUNCATE_TARGET option
ALTER TABLE [dbo].[FactInternetSales_20000101_20010101] SWITCH PARTITION 2 TO  [dbo].[FactInternetSales] PARTITION 2 WITH (TRUNCATE_TARGET = ON);

Další informace o opětovném vytváření oddílů pomocí CTAS naleznete v tématu Použití oddílů ve vyhrazeném fondu SQL.

Související obsah

Další informace o vývoji tabulek naleznete v tématu Vývoj tabulek.