Partitionerade tabeller och index

2025-06-30

gäller för:SQL Server Azure SQL Database Azure SQL Managed Instance

SQL Server, Azure SQL Database och Azure SQL Managed Instance stöder tabell- och indexpartitionering. Data för partitionerade tabeller och index är indelade i enheter som kan spridas över mer än en filgrupp i en databas eller lagras i en enda filgrupp. När det finns flera filer i en filgrupp sprids data över filer med hjälp av algoritmen för proportionell fyllning. Data partitioneras horisontellt, så att grupper av rader mappas till enskilda partitioner. Alla partitioner i ett enda index eller en tabell måste finnas i samma databas. Tabellen eller indexet behandlas som en enda logisk entitet när frågor eller uppdateringar utförs på data.

Före SQL Server 2016 (13.x) SP1 var partitionerade tabeller och index inte tillgängliga i varje version av SQL Server. En lista över funktioner som stöds av utgåvorna av SQL Server finns i Utgåvor och funktioner som stöds i SQL Server 2022. Partitionerade tabeller och index är tillgängliga på alla tjänstnivåer i Azure SQL Database och Azure SQL Managed Instance.

Tabellpartitionering är också tillgängligt i dedikerade SQL-pooler i Azure Synapse Analytics, med vissa syntaxskillnader. Läs mer i Partitioneringstabeller i dedikerade SQL-pooler.

Viktigt!

Databasmotorn stöder upp till 15 000 partitioner som standard. I tidigare versioner än SQL Server 2012 (11.x) begränsades antalet partitioner till 1 000 som standard.

Fördelar med partitionering

Partitionering av stora tabeller eller index kan ha följande hanterbarhets- och prestandafördelar.

Du kan överföra eller komma åt delmängder av data snabbt och effektivt, samtidigt som integriteten för en datainsamling bibehålls. Till exempel tar en åtgärd som att läsa in data från en OLTP till ett OLAP-system bara sekunder, i stället för de minuter och timmar som åtgärden tar när data inte partitioneras.
Du kan utföra underhålls- eller datakvarhållningsåtgärder på en eller flera partitioner snabbare. Åtgärderna är effektivare eftersom de endast riktar in sig på dessa dataunderuppsättningar, i stället för hela tabellen. Du kan till exempel välja att komprimera data i en eller flera partitioner, återskapa en eller flera partitioner av ett index eller trunkera data i en enda partition. Du kan också växla enskilda partitioner från en tabell och till en arkivtabell.
Du kan förbättra frågeprestandan baserat på de typer av frågor som du ofta kör. Frågeoptimeraren kan till exempel bearbeta likvärdiga frågor mellan två eller flera partitionerade tabeller snabbare när partitioneringskolumnerna är desamma som de kolumner som tabellerna är anslutna till. Mer information finns i avsnittet frågor.

Du kan förbättra prestanda genom att aktivera låseskalering på partitionsnivå i stället för en hel tabell. Detta kan minska låsblockeringen på tabellen. För att minska låskonkurrensen genom att tillåta låseskalering till partitionen, ställ in LOCK_ESCALATION alternativet för ALTER TABLE-statementet till AUTO.

Komponenter och begrepp

Följande villkor gäller för tabell- och indexpartitionering.

Partitionsfunktion

En partitionsfunktion är ett databasobjekt som definierar hur raderna i en tabell eller ett index mappas till en uppsättning partitioner baserat på värdena för en viss kolumn, som kallas för en partitioneringskolumn. Varje värde i partitioneringskolumnen är en indata till partitioneringsfunktionen, som returnerar ett partitionsvärde.

Partitionsfunktionen definierar antalet partitioner och de partitionsgränser som tabellen ska ha. Med en tabell som till exempel innehåller försäljningsorderdata kanske du vill partitionera tabellen i 12 partitioner (månadsvis) baserat på en datetime-kolumn , till exempel ett försäljningsdatum.

En intervalltyp (antingen VÄNSTER eller HÖGER) anger hur gränsvärdena för partitionsfunktionen ska placeras i de resulterande partitionerna:

Ett vänsterintervall anger att gränsvärdet tillhör vänster sida av gränsvärdesintervallet när intervallvärden sorteras efter databasmotorn i stigande ordning från vänster till höger. Med andra ord kommer det högsta gränsvärdet att inkluderas i en partition.
Ett RIGHT-intervall anger att gränsvärdet tillhör den högra sidan av gränsvärdesintervallet när intervallvärden sorteras efter databasmotorn i stigande ordning från vänster till höger. Med andra ord kommer det lägsta avgränsningsvärdet att inkluderas i varje partition.

Om VÄNSTER eller HÖGER inte har angetts är vänsterintervall standard.

Följande partitionsfunktion partitionerar till exempel en tabell eller ett index i 12 partitioner, en för varje månad som innehåller värden för ett år i en datetime-kolumn. Ett RIGHT-intervall används, vilket anger att gränsvärden fungerar som lägre avgränsningsvärden i varje partition. Högerintervall är ofta enklare att arbeta med vid partitionering av en tabell baserat på en kolumn med datatyperna datetime eller datetime2, eftersom rader med värdet midnatt lagras i samma partition som rader med senare värden på samma dag. På samma sätt, om du använder datatypen för datum och använder partitioner för en månad eller mer, behåller ett RIGHT-intervall den första dagen i månaden i samma partition som senare dagar i den månaden. Detta underlättar exakt partitionseliminering när du frågar efter en hel dags data.

CREATE PARTITION FUNCTION [myDateRangePF1] (datetime)
AS RANGE RIGHT FOR VALUES ('2022-02-01', '2022-03-01', '2022-04-01',
               '2022-05-01', '2022-06-01', '2022-07-01', '2022-08-01',
               '2022-09-01', '2022-10-01', '2022-11-01', '2022-12-01');

Följande tabell visar hur en tabell eller ett index som använder den här partitionsfunktionen vid partitionering av kolumn datecol partitioneras. Den 1 februari är den första gränspunkten som definieras i funktionen, så den fungerar som den nedre gränsen för partition 2.

Avdelning	1	2	...	11	12
Värden	datecol<`2022-02-01 12:00AM`	datecol>= `2022-02-01 12:00AM` AND datecol<`2022-03-01 12:00AM`		datecol>= `2022-11-01 12:00AM` AND col1<`2022-12-01 12:00AM`	datecol>= `2022-12-01 12:00AM`

För både RANGE LEFT och RANGE RIGHT har den vänstra partitionen det lägsta värdet för datatypen som den nedre gränsen, och den högra partitionen har det maximala värdet för datatypen som övre gräns.

Hitta fler exempel på funktioner för VÄNSTER- och HÖGERpartition i CREATE PARTITION FUNCTION.

Partitionsschema

Ett partitionsschema är ett databasobjekt som mappar partitionerna i en partitionsfunktion till en filgrupp eller till flera filgrupper.

Hitta exempelsyntax för att skapa partitionsscheman i CREATE PARTITION SCHEME.

Filgrupper

Den främsta orsaken till att du placerar partitionerna på flera filgrupper är att se till att du oberoende kan utföra säkerhetskopierings- och återställningsåtgärder på partitioner. Det beror på att du kan utföra säkerhetskopior på enskilda filgrupper. När du använder nivåindelad lagring kan du med flera filgrupper tilldela specifika partitioner till specifika lagringsnivåer, till exempel för att placera äldre och mindre ofta använda partitioner på långsammare och billigare lagring. Alla andra partitioneringsfördelar gäller oavsett antalet filgrupper som används eller partitionsplacering på specifika filgrupper.

Att hantera filer och filgrupper för partitionerade tabeller kan öka komplexiteten för administrativa uppgifter över tid. Om dina säkerhetskopierings- och återställningsprocedurer inte drar nytta av användningen av flera filgrupper rekommenderas en enda filgrupp för alla partitioner. Samma regler för att utforma filer och filgrupper gäller för partitionerade objekt som gäller för icke-partitionerade objekt.

Anmärkning

Partitionering stöds inte fullt ut i Azure SQL Database. Eftersom endast PRIMARY-filgruppen stöds i Azure SQL Database måste alla partitioner placeras i PRIMARY-filgruppen.

Hitta exempelkod för att skapa filgrupper för SQL Server och Azure SQL Managed Instance i ALTER DATABASE (Transact-SQL) Fil- och filgruppsalternativ.

Partitioneringskolumn

Kolumnen i en tabell eller ett index som en partitionsfunktion använder för att partitionera tabellen eller indexet. Följande överväganden gäller när du väljer en partitioneringskolumn:

Beräknade kolumner som deltar i en partitionsfunktion måste uttryckligen skapas som PERSISTED.
- Eftersom endast en kolumn kan användas som partitionskolumn kan sammanfogningen av flera kolumner med en beräknad kolumn i vissa fall vara användbar.
Kolumner av alla datatyper som är giltiga för användning som indexnyckelkolumner kan användas som en partitioneringskolumn, förutom tidsstämpel.
Kolumner med stora objektdatatyper (LOB), till exempel ntext, text, bild, xml, varchar(max), nvarchar(max)och varbinary(max), kan inte anges.
Det går inte att ange användardefinierade kolumner av typen Microsoft .NET Framework common language runtime (CLR) och aliasdatatyp.

Om du vill partitionera ett objekt anger du partitionsschemat och partitioneringskolumnen i uttrycken CREATE TABLE, ALTER TABLE och CREATE INDEX .

Om partition_scheme_name eller filgrupp inte har angetts och tabellen är partitionerad, placeras indexet i samma partitionsschema med samma partitioneringskolumn som den underliggande tabellen när du skapar ett icke-grupperat index. Om du vill ändra hur ett befintligt index partitioneras använder du CREATE INDEX med satsen DROP_EXISTING. På så sätt kan du partitionera ett icke-partitionerat index, göra ett partitionerat index icke-partitionerat eller ändra partitionsschemat för indexet.

Justerat index

Ett index som bygger på samma partitionsschema som motsvarande tabell. När en tabell och dess index är i justering kan databasmotorn snabbt och effektivt växla partitioner in eller ut ur tabellen samtidigt som partitionsstrukturen för både tabellen och dess index bibehålls. Ett index behöver inte delta i samma namngivna partitionsfunktion för att justeras mot bastabellen. Partitionsfunktionen för indexet och bastabellen måste dock vara i stort sett densamma, på så sätt:

Argumenten för partitionsfunktionerna har samma datatyp.
De definierar samma antal partitioner.
De definierar samma gränsvärden för partitioner.

Partitionering av klustrade indexí

När du partitionerar ett klustrat index måste klustringsnyckeln innehålla partitioneringskolumnen. När du partitionerar ett icke-substantivt klustrat index och partitioneringskolumnen inte uttryckligen anges i klustringsnyckeln lägger databasmotorn som standard till partitioneringskolumnen i listan över klustrade indexnycklar. Om det klustrade indexet är unikt måste du uttryckligen ange att den klustrade indexnyckeln innehåller partitioneringskolumnen. Mer information om klustrade index och indexarkitektur finns i Designriktlinjer för klustrade index.

Partitionering av icke-grupperade index

När du partitionerar ett unikt icke-grupperat index måste indexnyckeln innehålla partitioneringskolumnen. När du partitionerar ett icke-unikt, icke-klustrat index lägger databasmotorn till partitioneringskolumnen som standard som en icke-nyckelkolumn (ingår) i indexet för att säkerställa att indexet är i linje med bastabellen. Databasmotorn lägger inte till partitioneringskolumnen i indexet om den redan finns i indexet. Mer information om icke-grupperade index och indexarkitektur finns i Riktlinjer för icke-indexdesign.

Icke-justerat index

Ett nonaligned index partitioneras på ett annat sätt än motsvarande tabell. Indexet har alltså ett annat partitionsschema som placerar det på en separat filgrupp eller uppsättning filgrupper från bastabellen. Det kan vara användbart att utforma ett nonaligerat partitionerat index i följande fall:

Bastabellen har inte partitionerats.
Indexnyckeln är unik och innehåller inte tabellens partitioneringskolumn.
Du vill att grundtabellen ska delta i kollokaterade kopplingar med fler tabeller med hjälp av olika kopplingskolumner.

Partitionseliminering

Den process genom vilken frågeoptimeraren endast kommer åt relevanta partitioner för att uppfylla filtervillkoren för frågan.

Läs mer om partitionseliminering och relaterade begrepp i Förbättringar av frågebearbetning i partitionerade tabeller och index.

Begränsningar

Omfånget för en partitionsfunktion och ett schema är begränsat till den databas där de har skapats. I databasen finns partitionsfunktioner i ett separat namnområde från andra funktioner.
Om några rader i en partitionerad tabell har NULL:er i partitioneringskolumnen placeras dessa rader på den vänstra partitionen. Men om NULL anges som det första gränsvärdet och RANGE RIGHT anges i partitionsfunktionsdefinitionen förblir den vänstra partitionen tom och NULL:er placeras i den andra partitionen.

Riktlinjer för prestanda

Databasmotorn stöder upp till 15 000 partitioner per tabell eller index. Att använda mer än 1 000 partitioner har dock konsekvenser för minne, partitionerade indexåtgärder, DBCC-kommandon och frågor. Det här avsnittet beskriver prestandakonsekvenserna av att använda mer än 1 000 partitioner och tillhandahåller lösningar efter behov.

Med upp till 15 000 partitioner tillåtna per partitionerad tabell eller index kan du lagra data under långa perioder i en enda tabell. Du bör dock endast behålla data så länge de behövs och upprätthålla en balans mellan prestanda och antalet partitioner.

Minnesanvändning och riktlinjer

Vi rekommenderar att du använder minst 16 GB RAM-minne om ett stort antal partitioner används. Om systemet inte har tillräckligt med minne kan DML-instruktioner (Data Manipulation Language), DDL-instruktioner (Data Definition Language) och andra åtgärder misslyckas på grund av otillräckligt minne. System med 16 GB RAM-minne som kör många minnesintensiva processer kan få slut på minne på åtgärder som körs på ett stort antal partitioner. Ju mer minne du har över 16 GB, desto mindre troligt är det att du får prestanda- och minnesproblem.

Minnesbegränsningar kan påverka databasmotorns prestanda eller förmåga att skapa ett partitionerat index. Detta är särskilt fallet när indexet inte är justerat mot bastabellen eller inte är justerat mot det klustrade indexet, om tabellen redan har ett klustrat index.

I SQL Server och Azure SQL Managed Instance kan du öka index create memory (KB) serverkonfigurationsalternativet. Mer information finns i Serverkonfiguration: index skapa minne. För Azure SQL Database kan du överväga att tillfälligt eller permanent öka servicenivåmålet för databasen i Azure-portalen för att allokera mer minne.

Partitionerade indexåtgärder

Det är möjligt att skapa och återskapa nonaligerade index i en tabell med fler än 1 000 partitioner, men stöds inte. Detta kan orsaka försämrad prestanda eller överdriven minnesförbrukning under dessa åtgärder.

Det kan ta längre tid att skapa och återskapa justerade index när antalet partitioner ökar. Vi rekommenderar att du inte kör flera kommandon för att skapa och återskapa index samtidigt som du kan stöta på prestanda- och minnesproblem.

När databasmotorn utför sortering för att skapa partitionerade index skapar den först en sorteringstabell för varje partition. Sedan skapas sorteringstabellerna antingen i respektive filgrupp för varje partition eller i tempdb om alternativet SORT_IN_TEMPDB index har angetts. Varje sorteringstabell kräver en minsta mängd minne som ska skapas. När du skapar ett partitionerat index som är justerat efter bastabellen skapas sorteringstabeller en i taget med mindre minne. Men när du skapar ett nonaligerat partitionerat index skapas sorteringstabellerna samtidigt. Därför måste det finnas tillräckligt med minne för att hantera dessa samtidiga sorter. Ju större antal partitioner, desto mer minne krävs. Den minsta storleken för varje sorteringstabell för varje partition är 40 sidor med 8 kilobyte per sida. Ett nonaligerat partitionerat index med 100 partitioner kräver till exempel tillräckligt med minne för att sortera 4 000 sidor (40 * 100) sidor samtidigt. Om det här minnet är tillgängligt kommer byggåtgärden att lyckas, men prestanda kan bli lidande. Om det här minnet inte är tillgängligt misslyckas byggåtgärden. Alternativt kräver ett justerat partitionerat index med 100 partitioner endast tillräckligt med minne för att sortera 40 sidor, eftersom sorteringen inte utförs samtidigt.

För både inriktade och ojusterade index kan minnesbehovet vara större om databasmotorn använder frågeparallellisering för byggåtgärden på en dator med flera processorer. Det beror på att ju större grad av parallellitet (DOP), desto större minneskrav. Om databasmotorn till exempel anger DOP till 4 kräver ett nonaligerat partitionerat index med 100 partitioner tillräckligt med minne för att fyra processorer ska kunna sortera 4 000 sidor samtidigt eller 16 000 sidor. Om det partitionerade indexet är justerat minskas minnesbehovet till fyra processorer som sorterar 40 sidor eller 160 (4 * 40) sidor. Du kan använda alternativet MAXDOP-index för att manuellt minska parallellitetsgrader.

DBCC-kommandon

Med ett större antal partitioner kan DET ta längre tid att köra DBCC-kommandon som DBCC CHECKDB och DBCC CHECKTABLE när antalet partitioner ökar.

Frågor

Efter partitionering av en tabell eller ett index kan frågor som använder partitionseliminering ha jämförbara eller förbättrade prestanda med ett större antal partitioner. Frågor som inte använder partitionseliminering kan ta längre tid att köra när antalet partitioner ökar.

Anta till exempel att en tabell har 100 miljoner rader och kolumner A, Boch C.

I scenario 1 är tabellen uppdelad i 1 000 partitioner i kolumnen A.
I scenario 2 är tabellen uppdelad i 10 000 partitioner i kolumnen A.

En fråga i tabellen som har en WHERE satsfiltrering på kolumnen A utför partitionseliminering och genomsöker en partition. Samma fråga kan köras snabbare i scenario 2 eftersom det finns färre rader att skanna i en partition. En fråga som har en WHERE satsfiltrering på kolumn B genomsöker alla partitioner. Frågan kan köras snabbare i scenario 1 än i scenario 2 eftersom det finns färre partitioner att söka igenom.

Frågor som använder operatorer som TOP eller MAX/MIN på andra kolumner än partitioneringskolumnen kan få sämre prestanda med partitionering eftersom alla partitioner måste utvärderas.

På samma sätt tar en fråga som utför en enskild radsökning eller en liten intervallgenomsökning längre tid mot en partitionerad tabell än mot en icke-partitionerad tabell om frågepredikatet inte innehåller partitioneringskolumnen, eftersom den måste utföra så många sökningar eller genomsökningar som det finns partitioner. Därför förbättrar partitionering sällan prestanda i OLTP-system där sådana frågor är vanliga.

Om du ofta kör frågor som involverar en motsvarighet mellan två eller flera partitionerade tabeller bör deras partitioneringskolumner vara desamma som de kolumner som tabellerna är anslutna till. Dessutom bör tabellerna, eller deras index, vara sorterade. Det innebär att de antingen använder samma namngivna partitionsfunktion eller att de använder olika partitionsfunktioner som i stort sett är desamma, i så fall:

Ha samma antal parametrar som används för partitionering och motsvarande parametrar är samma datatyper.
Definiera samma antal partitioner.
Definiera samma gränsvärden för partitioner.

På så sätt kan frågeoptimeraren bearbeta kopplingen snabbare, eftersom själva partitionerna kan kopplas. Om en fråga ansluter till två tabeller som inte är sorterade eller inte partitioneras i kopplingsfältet, kan förekomsten av partitioner faktiskt göra frågebearbetningen långsammare i stället för att påskynda den.

Du kanske tycker att det är användbart att använda $PARTITION i vissa frågor. Läs mer i $PARTITION.

Mer information om partitionshantering vid frågebearbetning, inklusive strategi för parallell frågekörning för partitionerade tabeller och index, samt extra metodtips finns i Förbättringar av frågebearbetning i partitionerade tabeller och index.

Beteendeändringar i statistikberäkning under partitionerade indexåtgärder

I Azure SQL Database, Azure SQL Managed Instance och SQL Server 2012 (11.x) och senare skapas inte statistik genom att genomsöka alla rader i tabellen när ett partitionerat index skapas eller återskapas. I stället använder frågeoptimeraren standardsamplingsalgoritmen för att generera statistik.

När du har uppgraderat en databas med partitionerade index från en version av SQL Server som är lägre än 2012 (11.x) kanske du ser en skillnad i histogramdata för dessa index. Den här beteendeändringen kan påverka frågeprestanda. Om du vill hämta statistik om partitionerade index genom att skanna alla rader i tabellen använder du CREATE STATISTICS eller UPDATE STATISTICS med FULLSCAN-satsen.

Feedback

Var den här sidan till hjälp?