Columnstore-indexer: översikt

2025-04-14

gäller för:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)SQL-databas i Microsoft Fabric

Kolumnlagringsindex är standard för att lagra och fråga faktatabeller för stora datalager. Det här indexet använder kolumnbaserad datalagring och frågebearbetning för att uppnå vinster upp till 10 gånger frågeprestandan i ditt informationslager jämfört med traditionell radorienterad lagring. Du kan också uppnå vinster med upp till 10 gånger så hög datakomprimering jämfört med den okomprimerade datastorleken. Från och med SQL Server 2016 (13.x) SP1 möjliggör kolumnlagringsindex operationell analys: möjliggör att köra högpresterande realtidsanalyser på en transaktionell arbetsbelastning.

Lär dig mer om ett relaterat scenario:

Vad är ett columnstore-index?

Ett kolumnlagringsindex är en teknik för att lagra, hämta och hantera data med hjälp av ett kolumndataformat som kallas columnstore.

Viktiga termer och begrepp

Följande viktiga termer och begrepp är associerade med kolumnlagringsindex.

Kolumnarkiv

Ett kolumnlager är data som är logiskt ordnade som en tabell med rader och kolumner och som lagras fysiskt i ett kolumnmässigt dataformat.

Radbaserad lagring

Ett radlager är data som är logiskt ordnade som en tabell med rader och kolumner och som lagras fysiskt i ett radvist dataformat. Det här formatet är det traditionella sättet att lagra relationstabelldata. I SQL Server refererar radarkiv till en tabell där det underliggande datalagringsformatet är en heap, ett klustrat index eller en minnesoptimerad tabell.

Not

I diskussioner om kolumnlagringsindex används termerna rowstore och columnstore för att framhäva formatet för datalagringen.

Radgrupp

En radgrupp är en grupp rader som komprimeras till columnstore-format samtidigt. En radgrupp innehåller vanligtvis det maximala antalet rader per radgrupp, vilket är 1 048 576 rader.

För höga prestanda och höga komprimeringshastigheter segmenterar kolumnlagringsindex tabellen i radgrupper och komprimerar sedan varje radgrupp på ett kolumnmässigt sätt. Antalet rader i radgruppen måste vara tillräckligt stort för att förbättra komprimeringshastigheten och tillräckligt liten för att dra nytta av minnesinterna åtgärder.

En radgrupp där all data har tagits bort övergår från KOMPRIMERAD till TOMBSTONE och tas senare bort av en bakgrundsprocess som heter tuple-mover. Mer information om status för radgrupper finns i sys.dm_db_column_store_row_group_physical_stats (Transact-SQL).

Tips

Om du har för många små radgrupper minskar indexkvaliteten för kolumnlagring. Fram till SQL Server 2017 (14.x) krävs en omorganiseringsåtgärd för att sammanfoga mindre KOMPRIMERADE radgrupper, enligt en intern tröskelprincip som bestämmer hur du tar bort borttagna rader och kombinerar komprimerade radgrupper.
Från och med SQL Server 2019 (15.x) fungerar en bakgrundssammanslagningsaktivitet också för att sammanfoga KOMPRIMERADE radgrupper där ett stort antal rader har tagits bort.
När du har sammanfogat mindre radgrupper bör indexkvaliteten förbättras.

Not

Från och med SQL Server 2019 (15.x), Azure SQL Database, Azure SQL Managed Instance och dedikerade SQL-pooler i Azure Synapse Analytics, får tuppel-mover hjälp av en bakgrundssammanslagningsuppgift som automatiskt komprimerar mindre open delta-radgrupper som har funnits under en viss tid, vilket bestäms av ett internt tröskelvärde, eller sammanfogar komprimerade radgrupper där ett stort antal rader har tagits bort. Detta förbättrar kolumnlagringsindexets kvalitet över tid.

Kolumnavsnitt

Ett kolumnsegment är en kolumn med data inifrån radgruppen.

Varje radgrupp innehåller ett kolumnsegment för varje kolumn i tabellen.
Varje kolumnsegment komprimeras tillsammans och lagras på fysiska medier.
Det finns metadata med varje segment för att möjliggöra snabb eliminering av segment utan att läsa dem.

Logiskt diagram över kolumnsegment. Varje kolumn har ett kolumnsegment per radgrupp.

Grupperat kolumnlagringsindex

Ett grupperat columnstore-index är den fysiska lagringen för hela tabellen.

Logiskt diagram över ett grupperat kolumnlagringsindex. Innehåller komprimerade kolumnsegment plus rader i indexet, men inte i kolumnarkivet.

För att minska fragmenteringen av kolumnsegmenten och förbättra prestandan kan kolumnlagringsindexet tillfälligt lagra vissa data i ett grupperat index som kallas deltastore- och en B-trädlista med ID:n för borttagna rader. Deltastore-åtgärderna hanteras i bakgrunden. För att returnera rätt frågeresultat kombinerar det klustrade kolumnlagringsindexet frågeresultat från både kolumnarkivet och deltaarkivet.

Not

I dokumentationen används termen B-träd vanligtvis som referens till index. I radlagringsindex implementerar databasmotorn ett B+-träd. Detta gäller inte för kolumnlagringsindex eller index i minnesoptimerade tabeller. Mer information finns i arkitekturen och designguiden för SQL Server och Azure SQL-index.

Delta radgrupp

En deltaradgrupp är ett grupperat B-trädindex som endast används med kolumnlagringsindex. Det förbättrar kolumnlagringskomprimering och prestanda genom att lagra rader tills antalet rader når ett tröskelvärde (1 048 576 rader) och sedan flyttas till kolumnarkivet.

När en deltaradgrupp når det maximala antalet rader övergår den från tillståndet ÖPPNA till STÄNGD. En bakgrundsprocess med namnet tuple-mover söker efter stängda radgrupper. Om processen hittar en stängd radgrupp komprimerar den deltaradgruppen och lagrar den i kolumnarkivet som en KOMPRIMERAD radgrupp.

När en deltaradgrupp har komprimerats övergår den befintliga deltaradgruppen till TOMBSTONE-status för att senare tas bort av tuple-movern när det inte finns någon referens till den.

Mer information om status för radgrupper finns i sys.dm_db_column_store_row_group_physical_stats (Transact-SQL).

Not

Från och med SQL Server 2019 (15.x) får tuppel-mover hjälp av en bakgrundssammanslagningsaktivitet som automatiskt komprimerar mindre OPEN delta-radgrupper som har funnits under en tid enligt ett internt tröskelvärde, eller sammanfogar KOMPRIMERADE radgrupper där ett stort antal rader har tagits bort. Detta förbättrar kolumnlagringsindexets kvalitet över tid.

Deltastore

Ett kolumnlagringsindex kan ha mer än en deltaradgrupp. Alla deltaradgrupper kallas tillsammans deltaarkivet.

Under en stor bulk-inläsning går de flesta raderna direkt till kolumnarkivet utan att gå igenom deltaarkivet. Vissa rader i slutet av datamassinläsningen kan vara för få till antalet för att uppfylla den minsta storleken på en radgrupp, vilket är 102 400 rader. Därför går de sista raderna till deltalagret i stället för kolumnlagret. För små bulkbelastningar med färre än 102 400 rader går alla rader direkt till deltalagret.

Icke-grupperat columnstore-index

Ett icke-grupperat columnstore-index och ett grupperat columnstore-index fungerar på samma sätt. Skillnaden är att ett icke-grupperat index är ett sekundärt index som skapas i en radlagringstabell, men ett grupperat kolumnlagringsindex är den primära lagringen för hela tabellen.

Det icke-klustrerade indexet innehåller en kopia av en del av eller alla raderna och kolumnerna i den underliggande tabellen. Indexet definieras som en eller flera kolumner i tabellen och har ett valfritt villkor som filtrerar raderna.

Ett icke-grupperat columnstore-index möjliggör driftanalys i realtid där OLTP-arbetsbelastningen använder det underliggande klustrade indexet medan analys körs samtidigt på kolumnlagringsindexet. För mer information, se Kom igång med columnstore för driftanalys i realtid.

Körning av batchläge

Körning av batchläge är en frågebearbetningsmetod som används för att bearbeta flera rader tillsammans. Körning av batchläge är nära integrerat med och optimerat runt kolumnlagringsformatet. Körning av batchläge kallas ibland vektorbaserad eller vektoriserad körning. Frågor på columnstore-index använder körning av batchläge, vilket förbättrar frågeprestandan vanligtvis med två till fyra gånger. Mer information finns i arkitekturguiden Frågebearbetning.

Varför ska jag använda ett columnstore-index?

Ett kolumnlagringsindex kan ge en mycket hög nivå av datakomprimering, vanligtvis med 10 gånger, för att avsevärt minska lagringskostnaden för ditt informationslager. För analys erbjuder ett columnstore-index mer än tio gånger bättre prestanda jämfört med ett B-trädindex. Kolumnlagringsindex är det föredragna datalagringsformatet för datavaruhantering och analysarbetsuppgifter. Från och med SQL Server 2016 (13.x) kan du använda columnstore-index för realtidsanalys av din driftarbetsbelastning.

Orsaker till att kolumnlagringsindex är så snabba:

Kolumner lagrar värden från samma domän och har ofta liknande värden, vilket resulterar i höga komprimeringshastigheter. I/O-flaskhalsar i ditt system minimeras eller elimineras, och minnesanvändningen minskar avsevärt.
Hög kompressionsgrad förbättrar frågeprestanda genom att använda ett mindre minnesavtryck. Frågeprestanda kan i sin tur förbättras eftersom SQL Server kan utföra fler fråge- och dataåtgärder i minnet.
Batchkörning förbättrar frågeprestanda, vanligtvis med två till fyra gånger, genom att bearbeta flera rader tillsammans.
Frågor väljer ofta bara några kolumner från en tabell, vilket minskar det totala antalet I/O från det fysiska mediet.

När ska jag använda ett columnstore-index?

Rekommenderade användningsfall:

Använd ett grupperat kolumnlagringsindex för att lagra faktatabeller och stora dimensionstabeller för datalagerarbetsbelastningar. Den här metoden förbättrar frågeprestanda och datakomprimering med upp till 10 gånger. Mer information finns i Columnstore-indexer för datalager.
Använd ett icke-grupperat columnstore-index för att utföra analys i realtid på en OLTP-arbetsbelastning. För mer information, se Kom igång med columnstore för driftanalys i realtid.
Fler användningsscenarier för columnstore-index finns i Välj det bästa kolumnlagringsindexet för dina behov.

Hur väljer jag mellan ett radlagringsindex och ett kolumnlagringsindex?

Radlagringsindex presterar bäst på frågor som söker efter data, när du söker efter ett visst värde eller för frågor om ett litet värdeintervall. Använd radlagringsindex med transaktionsbelastningar eftersom de oftast kräver tabellsökningar i stället för tabellgenomsökningar.

Kolumnlagringsindex ger höga prestandavinster för analysfrågor som söker igenom stora mängder data, särskilt på stora tabeller. Använd columnstore-index för datalager- och analysarbetsbelastningar, särskilt i faktatabeller, eftersom de tenderar att kräva fullständiga tabellgenomsökningar i stället för tabellsökningar.

Ordnade grupperade kolumnlagringsindex förbättrar prestandan för frågor baserat på ordnade kolumnpredikat. Ordnade kolumnlagringsindex kan förbättra radgruppseliminering, vilket kan ge prestandaförbättringar genom att hoppa över radgrupper helt och hållet. Mer information finns i Prestandaoptimering med sorterade columnstore-index. Information om tillgänglighet för ordnat columnstore-index finns i Ordnad kolumnindextillgänglighet.

Kan jag kombinera radarkiv och kolumnarkiv i samma tabell?

Ja. Från och med SQL Server 2016 (13.x) kan du skapa ett uppdaterbart ickeklustrat kolumnstore-index på en radlagringstabell. Kolumnlagringsindexet lagrar en kopia av de valda kolumnerna, så du behöver extra utrymme för dessa data, men de valda data komprimeras i genomsnitt 10 gånger. Du kan köra analys på kolumnlagringsindexet och transaktionerna på radlagringsindexet samtidigt. Kolumnlagringen uppdateras när data ändras i radlagringstabellen, så båda indexen fungerar mot samma data.

Från och med SQL Server 2016 (13.x) kan du ha ett eller flera icke-klustrade radlagringsindex på ett kolumnlagringsindex och utföra effektiva tabellsökningar på den underliggande kolumnlagringen. Andra alternativ blir också tillgängliga. Du kan till exempel framtvinga en primärnyckelbegränsning med hjälp av en UNIK begränsning i radlagringstabellen. Eftersom ett icke-substantivt värde inte kan infogas i radlagringstabellen kan SQL Server inte infoga värdet i kolumnarkivet.

Ordnade kolumnlagringsindex

Genom att aktivera effektiv segmenteliminering ger ordnade kolumnlagringsindex snabbare prestanda genom att hoppa över stora mängder sorterade data som inte matchar frågepredikatet. Det kan ta längre tid att läsa in data i ett ordnat columnstore-index än i ett icke-ordnat index på grund av datasorteringsåtgärden, men med ordnade columnstore-index kan frågor köras snabbare efteråt.

Mer information om prestandajustering av datalagerarbetsbelastningar i SQL Database Engine med ordnade kolumnlagringsindex finns i Prestandajustering med ordnade kolumnlagringsindex.
Mer information om när du ska använda vilken typ av kolumnlagringsindex finns i Välj det bästa kolumnlagringsindexet för dina behov.

Ordnad tillgänglighet för columnstore-index

Ordnade kolumnlagringsindex är tillgängliga på följande plattformar:

Plattform	Ordnade grupperade kolumnlagringsindex	Ordnade icke-klustrade kolumnlagringsindex
Azure SQL Database	Ja	Ja
Azure SQL Managed Instance^AUTD	Ja	Ja
Azure SQL Managed Instance²⁰²²	Ja	Nej
SQL-databas i Microsoft Fabric	Ja¹	Ja
Förhandsversion av SQL Server 2025 (17.x)	Ja	Ja
SQL Server 2022 (16.x)	Ja	Nej
Dedikerad SQL-pool i Azure Synapse Analytics	Ja	Nej

^AUTD gäller för Azure SQL Managed Instance som konfigurerats med Always-up-to-date uppdateringsprincipen.
²⁰²² gäller för Azure SQL Managed Instance som konfigurerats med uppdateringsprincipen SQL Server 2022.
¹I Fabric SQL-databasen speglas inte tabeller med grupperade kolumnlagringsindex till Fabric OneLake-.

Metainformation

Alla kolumner i ett kolumnlagringsindex lagras i metadata som inkluderade kolumner. Kolumnlagringsindexet har inga nyckelkolumner.

sys.indexes (Transact-SQL)

sys.index_columns (Transact-SQL)

sys.partitions (Transact-SQL)

sys.internal_partitions (Transact-SQL)

sys.column_store_segments (Transact-SQL)

sys.column_store_dictionaries (Transact-SQL)

sys.column_store_row_groups (Transact-SQL)

sys.dm_db_column_store_row_group_operational_stats (Transact-SQL)

sys.dm_db_column_store_row_group_physical_stats (Transact-SQL)

sys.dm_column_store_object_pool (Transact-SQL)