SKAPA INDEX (Transact-SQL)

2025-04-09

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

Skapar ett relationsindex i en tabell eller vy. Kallas även för ett radlagringsindex eftersom det antingen är ett grupperat eller icke-grupperat B-trädindex. Du kan skapa ett radlagringsindex innan det finns data i tabellen. Använd ett radlagringsindex för att förbättra frågeprestanda, särskilt när frågorna väljer från specifika kolumner eller kräver att värden sorteras i en viss ordning.

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.

Azure Synapse Analytics and Analytics Platform System (PDW) stöder för närvarande inte unika begränsningar. Exempel som refererar till unika begränsningar gäller endast för SQL Server, Azure SQL Database och Azure SQL Managed Instance.

Information om riktlinjer för indexdesign finns i designguiden för SQL Server-index.

exempel:

Skapa ett icke-grupperat index i en tabell eller vy
```
CREATE INDEX index1 ON schema1.table1 (column1);
```
Skapa ett klustrat index i en tabell och använd ett 3-delsnamn för tabellen
```
CREATE CLUSTERED INDEX index1 ON database1.schema1.table1 (column1);
```

Skapa ett icke-grupperat index med en unik begränsning och ange sorteringsordningen

CREATE UNIQUE INDEX index1 ON schema1.table1 (column1 DESC, column2 ASC, column3 DESC);

Nyckelscenario:

Från och med SQL Server 2016 (13.x), i Azure SQL Database och i Azure SQL Managed Instance kan du använda ett icke-grupperat index på ett kolumnlagringsindex för att förbättra frågeprestanda för datalager. Mer information finns i Columnstore-index – informationslager.

Ytterligare typer av index finns i:

Transact-SQL syntaxkonventioner

Syntax

Syntax för SQL Server, Azure SQL Database, Azure SQL Managed Instance

CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
    ON <object> ( column [ ASC | DESC ] [ ,...n ] )
    [ INCLUDE ( column_name [ ,...n ] ) ]
    [ WHERE <filter_predicate> ]
    [ WITH ( <relational_index_option> [ ,...n ] ) ]
    [ ON { partition_scheme_name ( column_name )
         | filegroup_name
         | default
         }
    ]
    [ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]

[ ; ]

<object> ::=
{ database_name.schema_name.table_or_view_name | schema_name.table_or_view_name | table_or_view_name }

<relational_index_option> ::=
{
    PAD_INDEX = { ON | OFF }
  | FILLFACTOR = fillfactor
  | SORT_IN_TEMPDB = { ON | OFF }
  | IGNORE_DUP_KEY = { ON | OFF }
  | STATISTICS_NORECOMPUTE = { ON | OFF }
  | STATISTICS_INCREMENTAL = { ON | OFF }
  | DROP_EXISTING = { ON | OFF }
  | ONLINE = { ON [ ( <low_priority_lock_wait> ) ] | OFF }
  | RESUMABLE = { ON | OFF }
  | MAX_DURATION = <time> [MINUTES]
  | ALLOW_ROW_LOCKS = { ON | OFF }
  | ALLOW_PAGE_LOCKS = { ON | OFF }
  | OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | OFF }
  | MAXDOP = max_degree_of_parallelism
  | DATA_COMPRESSION = { NONE | ROW | PAGE }
     [ ON PARTITIONS ( { <partition_number_expression> | <range> }
     [ , ...n ] ) ]
  | XML_COMPRESSION = { ON | OFF }
     [ ON PARTITIONS ( { <partition_number_expression> | <range> }
     [ , ...n ] ) ]
}

<filter_predicate> ::=
    <conjunct> [ AND ] [ ...n ]

<conjunct> ::=
    <disjunct> | <comparison>

<disjunct> ::=
        column_name IN (constant ,...n)

<comparison> ::=
        column_name <comparison_op> constant

<comparison_op> ::=
    { IS | IS NOT | = | <> | != | > | >= | !> | < | <= | !< }

<low_priority_lock_wait>::=
{
    WAIT_AT_LOW_PRIORITY ( MAX_DURATION = <time> [ MINUTES ] ,
                          ABORT_AFTER_WAIT = { NONE | SELF | BLOCKERS } )
}

<range> ::=
<partition_number_expression> TO <partition_number_expression>

Bakåtkompatibelt relationsindex

Viktig

Den bakåtkompatibla syntaxstrukturen för relationsindex tas bort i en framtida version av SQL Server. Undvik att använda den här syntaxstrukturen i det nya utvecklingsarbetet och planera att ändra program som för närvarande använder funktionen. Använd syntaxstrukturen som anges i <relational_index_option> i stället.

CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
    ON <object> ( column_name [ ASC | DESC ] [ ,...n ] )
    [ WITH <backward_compatible_index_option> [ ,...n ] ]
    [ ON { filegroup_name | "default" } ]

<object> ::=
{
    [ database_name. [ owner_name ] . | owner_name. ]
    table_or_view_name
}

<backward_compatible_index_option> ::=
{
    PAD_INDEX
  | FILLFACTOR = fillfactor
  | SORT_IN_TEMPDB
  | IGNORE_DUP_KEY
  | STATISTICS_NORECOMPUTE
  | DROP_EXISTING
}

Syntax för Azure Synapse Analytics och Parallel Data Warehouse


CREATE CLUSTERED COLUMNSTORE INDEX index_name
    ON [ database_name . [ schema ] . | schema . ] table_name
    [ORDER (column[,...n])]
    [WITH ( DROP_EXISTING = { ON | OFF } )]
[;]


CREATE [ CLUSTERED | NONCLUSTERED ] INDEX index_name
    ON [ database_name . [ schema ] . | schema . ] table_name
        ( { column [ ASC | DESC ] } [ ,...n ] )
    WITH ( DROP_EXISTING = { ON | OFF } )
[;]

Argument

UNIK

Skapar ett unikt index i en tabell eller vy. Ett unikt index är ett där inga två rader tillåts ha samma indexnyckelvärde.

Databasmotorn tillåter inte att du skapar ett unikt index för kolumner som redan innehåller dubblettvärden, oavsett om IGNORE_DUP_KEY det är inställt ONpå . Om detta görs visar databasmotorn ett felmeddelande. Dubblettvärden måste tas bort innan ett unikt index kan skapas i kolumnen eller kolumnerna.

En UNIQUE begränsning behandlas NULL som ett värde. Om en kolumn är nullbar och det finns en UNIQUE begränsning i kolumnen tillåts högst en rad med en NULL .

KLUSTRADE

Skapar ett index där den sorteringsordning som angetts för indexnyckelkolumnerna avgör sidordningen i indexstrukturen på disken. Rader på sidorna längst ned eller på lövnivån för det klustrade indexet innehåller alltid alla kolumner i tabellen. Rader på sidorna i indexets övre nivåer innehåller endast nyckelkolumner.

En tabell kan bara ha ett grupperat index. Om det finns ett grupperat index i en tabell innehåller det alla data i tabellen. En tabell utan ett klustrat index kallas för en heap.

En vy med ett unikt grupperat index kallas för en indexerad vy. En indexerad vy kan bara ha ett grupperat index. När du skapar ett unikt grupperat index i en vy materialiseras vyn fysiskt. Ett unikt grupperat index måste skapas i en vy innan andra index kan definieras i samma vy. Mer information finns i Skapa indexerade vyer.

Skapa det klustrade indexet innan du skapar några icke-grupperade index. Befintliga icke-grupperade index i tabeller återskapas när ett klustrat index skapas, vilket är en resursintensiv åtgärd om tabellen är stor.

Om CLUSTERED inte anges skapas ett icke-grupperat index.

Not

Eftersom det klustrade indexet innehåller alla data i tabellen flyttas tabellen från den filgrupp där tabellen skapades till det nya partitionsschemat eller filgruppen genom att skapa ett grupperat index och använda -instruktionen eller med hjälp av ON partition_scheme_name -instruktionen ON filegroup_name . Innan du skapar tabeller eller index för specifika filgrupper kontrollerar du vilka filgrupper som är tillgängliga och att de har tillräckligt med tomt utrymme för indexet.

I vissa fall kan du aktivera tidigare inaktiverade index genom att skapa ett grupperat index. Mer information finns i Aktivera index och begränsningar och Inaktivera index och begränsningar.

NONCLUSTERED

Skapar ett index där den sorteringsordning som angetts för indexnyckelkolumnerna avgör sidordningen i indexstrukturen på disken. Till skillnad från det klustrade indexet innehåller rader på sidorna på lövnivån för ett icke-grupperat index endast indexnyckelkolumnerna. Du kan också inkludera en delmängd av icke-nyckelkolumner med hjälp av INCLUDE -satsen.

Varje tabell kan ha upp till 999 icke-illustrerade index, oavsett hur indexen skapas: antingen implicit med PRIMARY KEY begränsningarna och UNIQUE eller explicit med CREATE INDEX.

För indexerade vyer kan icke-grupperade index endast skapas i en vy som har ett unikt grupperat index som redan har definierats.

Om inget annat anges är standardindextypen inte illustrerad.

index_name

Namnet på indexet. Indexnamn måste vara unika i en tabell eller vy, men behöver inte vara unika i en databas. Indexnamn måste följa reglerna för identifierare.

kolumn

Kolumnen eller kolumnerna som indexet baseras på. Ange två eller flera kolumnnamn för att skapa ett sammansatt index för de kombinerade värdena i de angivna kolumnerna. Visa en lista över de kolumner som ska ingå i det sammansatta indexet, i sorteringsprioritetsordning, inom parenteserna efter table_or_view_name.

Upp till 32 kolumner kan kombineras till en enda sammansatt indexnyckel. Alla kolumner i en sammansatt indexnyckel måste finnas i samma tabell eller vy. Den maximala tillåtna storleken för de kombinerade indexvärdena är 900 byte för ett grupperat index, eller 1 700 för ett icke-grupperat index. Gränserna är 16 kolumner och 900 byte för versioner före SQL Database och SQL Server 2016 (13.x).

Kolumner som är av de stora objektdatatyperna (LOB) ntext, text, varchar(max), nvarchar(max), varbinary(max), xmleller bild inte kan anges som nyckelkolumner för ett index. Dessutom kan en indexerad vydefinition inte innehålla ntext-, text- eller bildkolumner , även om de inte refereras till i -instruktionen CREATE INDEX .

Du kan skapa index för CLR-användardefinierade typkolumner om typen stöder binär ordning. Du kan också skapa index för beräknade kolumner som definieras som metodanrop från en användardefinierad typkolumn, så länge metoderna är markerade som deterministiska och inte utför dataåtkomståtgärder. Mer information om hur du indexerar CLR-användardefinierade typkolumner finns i CLR-användardefinierade typer.

[ ASC | DESC ]

Avgör stigande eller fallande sorteringsriktning för den specifika indexkolumnen. Standardvärdet är ASC.

INCLUDE (column [ ,... n ] )

Anger de icke-nyckelkolumner som ska läggas till på lövnivån för ett icke-grupperat index. Det icke-illustrerade indexet kan vara unikt eller icke-unikt.

Kolumnnamn kan inte upprepas i INCLUDE listan och kan inte användas samtidigt som både nyckelkolumner och icke-nyckelkolumner. Icke-grupperade index innehåller alltid implicit de klustrade indexkolumnerna om ett klustrat index definieras i tabellen. Mer information finns i Skapa index med inkluderade kolumner.

Alla datatyper tillåts förutom text, ntextoch bild. Från och med SQL Server 2012 (11.x), i Azure SQL Database och i Azure SQL Managed Instance, om någon av de angivna icke-nyckelkolumnerna är varchar(max), nvarchar(max)eller varbinary(max) datatyper, kan indexet skapas eller återskapas med hjälp av ONLINE alternativet .

Beräknade kolumner som är deterministiska och antingen exakta eller oprecisa kan inkluderas kolumner. Beräknade kolumner som härleds från datatyperna image, ntext, text, varchar(max), nvarchar(max), varbinary(max) och xml kan inkluderas så länge datatypen för den beräknade kolumnen är tillåten som en inkluderad kolumn. Mer information finns i Index över beräknade kolumner.

Information om hur du skapar ett XML-index finns i CREATE XML INDEX.

VAR <filter_predicate>

Skapar ett filtrerat index genom att ange vilka rader som ska inkluderas i indexet. Det filtrerade indexet måste vara ett icke-grupperat index i en tabell. Skapar filtrerad statistik för dataraderna i det filtrerade indexet.

Filterpredikatet använder enkel jämförelselogik och kan inte referera till en beräknad kolumn, en användardefinierad datatypkolumn (UDT), en kolumn för rumslig datatyp eller en hierarkiiddatatypkolumn . Jämförelser med NULL literaler med hjälp av jämförelseoperatorerna tillåts inte. Använd operatorerna IS NULL och IS NOT NULL i stället.

Här följer några exempel på filterpredikat för tabellen Production.BillOfMaterials:

WHERE StartDate > '20000101' AND EndDate <= '20000630'

WHERE ComponentID IN (533, 324, 753)

WHERE StartDate IN ('20000404', '20000905') AND EndDate IS NOT NULL

Filtrerade index gäller inte för XML-index och fulltextindex. För UNIQUE index måste endast de markerade raderna ha unika indexvärden. Filtrerade index tillåter inte alternativet IGNORE_DUP_KEY.

PÅ partition_scheme_name ( column_name )

Anger partitionsschemat som definierar de filgrupper som partitionerna i ett partitionerat index mappas till. Partitionsschemat måste finnas i databasen genom att antingen köra CREATE PARTITION SCHEME eller ALTER PARTITION SCHEME. column_name anger partitioneringskolumnen för indexet. Den här kolumnen måste matcha datatypen, längden och precisionen för argumentet för partitionsfunktionen som partition_scheme_name använder. column_name är inte begränsat till kolumnerna i indexdefinitionen. Alla kolumner i bastabellen kan anges, förutom när du partitionerar ett unikt index , column_name måste väljas bland dem som används som unik nyckel. Med den här begränsningen kan databasmotorn endast verifiera att nyckelvärdena är unika inom en enda partition.

Not

När du partitionerar ett icke-unikt grupperat index lägger databasmotorn som standard till partitioneringskolumnen i listan över klustrade indexnycklar, om den inte redan har angetts. När du partitionerar ett icke-unikt, icke-grupperat index lägger databasmotorn till partitioneringskolumnen som en icke-nyckelkolumn (ingår) i indexet, om den inte redan har angetts.

Om partition_scheme_name eller filgrupp inte anges och tabellen partitioneras placeras indexet i samma partitionsschema med samma partitioneringskolumn som den underliggande tabellen.

Not

Du kan inte ange ett partitioneringsschema för ett XML-index. Om bastabellen är partitionerad använder XML-indexet samma partitionsschema som tabellen.

Mer information om partitionering av index, partitionerade tabeller och index.

PÅ filegroup_name

Skapar det angivna indexet för den angivna filgruppen. Om ingen plats har angetts och tabellen eller vyn inte är partitionerad använder indexet samma filgrupp som den underliggande tabellen eller vyn. Filgruppen måste redan finnas.

PÅ [standard]

Skapar det angivna indexet för samma filgrupps- eller partitionsschema som tabellen eller vyn.

Termen default, i den här kontexten, är inte ett nyckelord. Det är en identifierare för filgruppen eller partitionerat schema i tabellen eller vyn och måste avgränsas, som i ON "default" eller ON [default]. Om "default" anges måste alternativet QUOTED_IDENTIFIER vara ON för den aktuella sessionen. Det här är standardinställningen. Mer information finns i SET QUOTED_IDENTIFIER.

Not

I kontexten CREATE INDEXför , "default" och [default] ange inte databasens standardfilgrupp. De anger det filgrupps- eller partitionsschema som används av bastabellen eller vyn. Detta skiljer sig från CREATE TABLE, där "default" och [default] placerar tabellen i databasens standardfilgrupp.

[ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]

Anger placeringen av FILESTREAM-data för tabellen när ett klustrat index skapas. Med FILESTREAM_ON-satsen kan FILESTREAM-data flyttas till ett annat FILESTREAM-filgrupps- eller partitionsschema.

Filestream_filegroup_name är namnet på en FILESTREAM-filgrupp. Filgruppen måste ha en fil definierad för filgruppen med hjälp av en CREATE DATABASE eller ALTER DATABASE-instruktion. annars utlöses ett fel.

Om tabellen är partitionerad måste FILESTREAM_ON-satsen inkluderas och måste ange ett partitionsschema med FILESTREAM-filgrupper som använder samma partitionsfunktion och partitionskolumner som partitionsschemat för tabellen. Annars utlöses ett fel.

Om tabellen inte är partitionerad kan kolumnen FILESTREAM inte partitioneras. FILESTREAM-data för tabellen måste lagras i en enda filgrupp som anges i FILESTREAM_ON-satsen.

FILESTREAM_ON NULL kan anges i en CREATE INDEX-instruktion om ett klustrat index skapas och tabellen inte innehåller någon FILESTREAM-kolumn.

Mer information finns i FILESTREAM (SQL Server).

<objekt>::=

Det fullständigt kvalificerade eller icke-kvalificerade objekt som ska indexeras.

database_name

Namnet på databasen.

schema_name

Namnet på schemat som tabellen eller vyn tillhör.

table_or_view_name

Namnet på tabellen eller vyn som ska indexeras.

Om du vill skapa ett index i en vy måste vyn definieras med SCHEMABINDING. Ett unikt grupperat index måste skapas i en vy innan ett icke-grupperat index skapas. Mer information om indexerade vyer finns i Kommentarer.

Från och med SQL Server 2016 (13.x) kan objektet vara en tabell som lagras med ett grupperat columnstore-index.

Azure SQL Database stöder namnformatet i tre delar <database_name>.<schema_name>.<object_name> när <database_name> är det aktuella databasnamnet eller <database_name> är tempdb och <object_name> börjar med # eller ##. Om schemanamnet är dbokan <schema_name> utelämnas.

<relational_index_option>::=

Anger vilka alternativ som ska användas när du skapar indexet.

PAD_INDEX = { ON | AV }

Anger indexutfyllnad. Standardvärdet är OFF.

PÅ

Procentandelen ledigt utrymme som anges av fyllningsfaktorn tillämpas på sidorna på mellannivå i indexet. Om FILLFACTOR inte anges samtidigt PAD_INDEX anges till ONanvänds fyllningsfaktorvärdet i sys.indexes.
BORT

Sidorna på mellannivå fylls till nära kapacitet, vilket ger tillräckligt med utrymme för minst en rad av den maximala storlek som indexet kan ha, med tanke på uppsättningen nycklar på mellanliggande sidor. Detta inträffar också om PAD_INDEX är inställt på ON men fyllningsfaktorn inte har angetts.

Alternativet PAD_INDEX är bara användbart när FILLFACTOR anges, eftersom PAD_INDEX använder den procentandel som anges av FILLFACTOR. Om procentandelen som angetts för FILLFACTOR inte är tillräckligt stor för att tillåta en rad åsidosätter databasmotorn internt procentandelen för att tillåta ett minimum. Antalet rader på en mellanliggande indexsida är aldrig mindre än två, oavsett hur lågt värdet FILLFACTORför .

I bakåtkompatibel syntax motsvarar WITH PAD_INDEXWITH PAD_INDEX = ON.

FILLFACTOR = fillfactor

Anger en procentandel som anger hur full databasmotorn ska göra lövnivån för varje indexsida när index skapas eller återskapas. Fillfactor-värdet måste vara ett heltalsvärde från 1 till 100. Fyllningsfaktorvärdena 0 och 100 är desamma i alla avseenden. Om fillfactor- är 100 skapar databasmotorn index med lövsidor fyllda till kapacitet.

Inställningen FILLFACTOR gäller endast när indexet skapas eller återskapas. Databasmotorn behåller inte dynamiskt den angivna procentandelen tomt utrymme på sidorna.

Om du vill visa fyllningsfaktorinställningen fill_factor använder du kolumnen i katalogvyn sys.indexes .

Viktig

Om du skapar ett index med en FILLFACTOR mindre än 100 ökar mängden lagringsutrymme som data upptar eftersom databasmotorn omdistribuerar data enligt fyllningsfaktorn när det skapar eller återskapar ett index.

Mer information finns i Ange fyllningsfaktor för ett index.

SORT_IN_TEMPDB = { ON | AV }

Anger om tillfälliga sorteringsresultat ska lagras i tempdb. Standardvärdet är OFF förutom Azure SQL Database Hyperscale. För alla index build-åtgärder i Hyperskala är SORT_IN_TEMPDB alltid ON om inte en återanvändbar indexversion används. För återupptabara indexversioner är SORT_IN_TEMPDB alltid OFF.

PÅ

Mellanliggande sorteringsresultat som används för att skapa indexet lagras i tempdb. Detta kan minska den tid som krävs för att skapa ett index. Detta ökar dock mängden diskutrymme som används under indexversionen.
BORT

Mellanliggande sorteringsresultat lagras i samma databas som indexet.

Förutom det utrymme som krävs i användardatabasen för att skapa indexet tempdb måste det ha ungefär samma mängd extra utrymme för att lagra mellanliggande sorteringsresultat. Mer information finns i SORT_IN_TEMPDB alternativet för index.

I bakåtkompatibel syntax motsvarar WITH SORT_IN_TEMPDBWITH SORT_IN_TEMPDB = ON.

IGNORE_DUP_KEY = { ON | AV }

Anger felsvaret när en infogningsåtgärd försöker infoga dubblettnyckelvärden i ett unikt index. Alternativet IGNORE_DUP_KEY gäller endast för infogningsåtgärder när indexet har skapats eller återskapats. Alternativet har ingen effekt när du kör CREATE INDEX, ALTER INDEXeller UPDATE. Standardvärdet är OFF.

PÅ

Ett varningsmeddelande inträffar när dubbletter av nyckelvärden infogas i ett unikt index. Endast de rader som bryter mot unikhetsbegränsningen infogas inte.
BORT

Ett felmeddelande uppstår när dubbletter av nyckelvärden infogas i ett unikt index. Hela INSERT instruktionen återställs.

IGNORE_DUP_KEY kan inte anges till ON för index som skapats i en vy, icke-unika index, XML-index, rumsliga index och filtrerade index.

Om du vill visa inställningen IGNORE_DUP_KEY för ett index använder du kolumnen ignore_dup_key i sys.indexes katalogvy.

I bakåtkompatibel syntax motsvarar WITH IGNORE_DUP_KEYWITH IGNORE_DUP_KEY = ON.

STATISTICS_NORECOMPUTE = { ON | OFF}

Anger om statistik omberäknas. Standardvärdet är OFF.

PÅ

Inaktuell statistik omberäknas inte automatiskt.
BORT

Automatisk uppdatering av statistik är aktiverade.

Om du vill återställa automatisk uppdatering av statistik ställer du in STATISTICS_NORECOMPUTE på AV eller kör UPDATE STATISTICS utan NORECOMPUTE-satsen.

Varning

Om du inaktiverar automatisk omberäkning av statistik genom att ange STATISTICS_NORECOMPUTE = ONkan du förhindra att frågeoptimeraren väljer optimala körningsplaner för frågor som involverar tabellen.

Om du anger STATISTICS_NORECOMPUTE till ON hindrar inte uppdateringen av indexstatistiken som inträffar under indexet återskapandeåtgärden.

I bakåtkompatibel syntax motsvarar WITH STATISTICS_NORECOMPUTEWITH STATISTICS_NORECOMPUTE = ON.

STATISTICS_INCREMENTAL = { ON | AV }

gäller för: SQL Server 2014 (12.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

När ONär den statistik som skapas per partitionsstatistik. När OFFtas statistikträdet bort och SQL Server beräknar statistiken igen. Standardvärdet är OFF.

Om statistik per partition inte stöds ignoreras alternativet och en varning genereras. Inkrementell statistik stöds inte i följande fall:

Statistik som skapats med index som inte är partitionsjusterade med bastabellen.
Statistik som skapats på skrivbara sekundära databaser med AlwaysOn.
Statistik som skapats på skrivskyddade databaser.
Statistik som skapats för filtrerade index.
Statistik som skapats för vyer.
Statistik som skapats i interna tabeller.
Statistik som skapats med rumsliga index eller XML-index.

DROP_EXISTING = { ON | AV }

Är ett alternativ för att släppa och återskapa det befintliga klustrade eller icke-grupperade indexet med ändrade kolumnspecifikationer och behålla samma namn för indexet. Standardvärdet är OFF.

PÅ

Anger för att släppa och återskapa det befintliga indexet, som måste ha samma namn som parametern index_name.
BORT

Anger att det befintliga indexet inte ska släppas och återskapas. SQL Server visar ett fel om det angivna indexnamnet redan finns.

Med DROP_EXISTINGkan du ändra:

Ett icke-grupperat radlagringsindex till ett grupperat radlagringsindex.

Med DROP_EXISTINGkan du inte ändra:

Ett grupperat radlagringsindex till ett icke-grupperat radlagringsindex.
Ett grupperat columnstore-index till alla typer av radlagringsindex.

I bakåtkompatibel syntax motsvarar WITH DROP_EXISTINGWITH DROP_EXISTING = ON.

ONLINE = { ON | AV }

Anger om underliggande tabeller och associerade index är tillgängliga för frågor och dataändringar under indexåtgärden. Standardvärdet är OFF.

Viktig

Onlineindexåtgärder är inte tillgängliga i varje utgåva av Microsoft SQL Server. En lista över funktioner som stöds av versionerna av SQL Server finns i Utgåvor och funktioner som stöds i SQL Server 2022.

PÅ

Långsiktiga tabelllås hålls inte under indexåtgärdens varaktighet. Under huvudfasen av indexåtgärden lagras endast ett delat avsiktslås (IS) i källtabellen. Detta gör att frågor eller uppdateringar av den underliggande tabellen och index kan fortsätta. I början av åtgärden hålls ett delat (S) lås på källobjektet under en kort tidsperiod. I slutet av åtgärden, under en kort tidsperiod, hämtas ett delat (S) lås på objektet om ett icke-grupperat index skapas. Ett schemaändringslås (Sch-M) hämtas när ett klustrat index skapas eller tas bort online och när ett klustrat eller icke-grupperat index återskapas. ONLINE kan inte anges till ON när ett index skapas i en lokal tillfällig tabell.

Not

Du kan använda alternativet WAIT_AT_LOW_PRIORITY för att minska eller undvika blockering under onlineindexåtgärder. Mer information finns i WAIT_AT_LOW_PRIORITY med onlineindexåtgärder.
BORT

Tabelllås tillämpas under indexåtgärdens varaktighet. En offlineindexåtgärd som skapar, återskapar eller släpper ett klustrat, rumsligt index eller XML-index, eller återskapar eller släpper ett icke-grupperat index, hämtar ett schemaändringslås (Sch-M) i tabellen. Detta förhindrar all användaråtkomst till den underliggande tabellen under hela åtgärden. En offlineindexåtgärd som skapar ett icke-grupperat index hämtar ursprungligen ett delat lås (S) i tabellen. Detta förhindrar ändringar av den underliggande tabelldefinitionen, men tillåter läsning och ändring av data i tabellen medan indexet byggs.

Mer information finns i Utföra indexåtgärder online och riktlinjer för onlineindexåtgärder.

Index, inklusive index i globala temporära tabeller, kan skapas online förutom i följande fall:

XML-index
Index i en lokal temporär tabell
Första unika klustrade index i en vy
Inaktiverade klustrade index
Grupperade columnstore-index i SQL Server 2017 (14.x)) och äldre versioner
Icke-illustrerade kolumnlagringsindex i SQL Server 2016 (13.x)) och äldre versioner
Grupperat index, om den underliggande tabellen innehåller LOB-datatyper (bild, ntext, text) och rumsliga datatyper
varchar(max) och varbinary(max) kolumner kan inte ingå i en indexnyckel. I SQL Server (från och med SQL Server 2012 (11.x)), i Azure SQL Database och i Azure SQL Managed Instance, när en tabell innehåller kolumner med varchar(max) eller varbinary(max), kan ett klustrat index som innehåller andra kolumner byggas eller återskapas med hjälp av ONLINE alternativet .
Icke-grupperade index i en tabell med ett grupperat columnstore-index

Mer information finns i Hur onlineindexåtgärder fungerar.

RESUMABLE = { ON | AV }

gäller för: SQL Server 2019 (15.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

Anger om en onlineindexåtgärd kan återupptas. Mer information finns i Återupptabara indexåtgärder och Överväganden för återanvändbara index.

PÅ

Indexåtgärden kan återupptas.
BORT

Indexåtgärden kan inte återupptas.

MAX_DURATION = tid [MINUTER] som används med `RESUMABLE = ON` (kräver `ONLINE = ON`)

gäller för: SQL Server 2019 (15.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

Anger hur länge, i minuter, en återupptabar indexåtgärd körs innan den pausas.

ALLOW_ROW_LOCKS = { ON | AV }

Anger om radlås tillåts. Standardvärdet är ON.

PÅ

Radlås tillåts vid åtkomst till indexet. Databasmotorn avgör när radlås används.
BORT

Radlås används inte.

ALLOW_PAGE_LOCKS = { ON | AV }

Anger om sidlås tillåts. Standardvärdet är ON.

PÅ

Sidlås tillåts vid åtkomst till indexet. Databasmotorn avgör när sidlås används.
BORT

Sidlås används inte.

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | AV }

gäller för: SQL Server 2019 (15.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

Anger om du vill optimera för att undvika infogningskonkurnation på sista sidan. Standardvärdet är OFF. Mer information finns i avsnittet Sekventiella nycklar .

MAXDOP = max_degree_of_parallelism

Åsidosätter maximal grad av parallellitet konfigurationsalternativ för indexåtgärden. Mer information finns i Konfigurera den maximala graden av parallellitet serverkonfigurationsalternativ. Använd MAXDOP för att begränsa graden av parallellitet och den resulterande resursförbrukningen för en indexgenereringsåtgärd.

max_degree_of_parallelism kan vara:

1

Undertrycker parallell plangenerering.
>1

Begränsar den maximala grad av parallellitet som används i en parallell indexåtgärd till det angivna talet eller mindre baserat på den aktuella systemarbetsbelastningen.
0 (standard)

Använder den grad av parallellitet som anges på server-, databas- eller arbetsbelastningsgruppsnivå, såvida den inte minskas baserat på den aktuella systemarbetsbelastningen.

Mer information finns i Konfigurera parallella indexåtgärder.

Not

Parallella indexåtgärder är inte tillgängliga i varje utgåva av Microsoft SQL Server. En lista över funktioner som stöds av versionerna av SQL Server finns i Utgåvor och funktioner som stöds i SQL Server 2022.

DATA_COMPRESSION

Anger datakomprimeringsalternativet för det angivna indexet, partitionsnumret eller partitionsintervallet. Alternativen är följande:

INGEN

Index eller angivna partitioner komprimeras inte. Detta gäller inte för kolumnlagringsindex.
RAD

Index eller angivna partitioner komprimeras med hjälp av radkomprimering. Detta gäller inte för kolumnlagringsindex.
SIDA

Index eller angivna partitioner komprimeras med hjälp av sidkomprimering. Detta gäller inte för kolumnlagringsindex.
COLUMNSTORE

gäller för: SQL Server 2014 (12.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

Gäller endast för columnstore-index, inklusive både icke-grupperade kolumnarkiv och grupperade kolumnlagringsindex.
COLUMNSTORE_ARCHIVE

gäller för: SQL Server 2014 (12.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

Gäller endast för columnstore-index, inklusive både icke-grupperade kolumnarkiv och grupperade kolumnlagringsindex. COLUMNSTORE_ARCHIVE komprimerar den angivna partitionen ytterligare till en mindre storlek. Detta kan användas för arkivering, eller för andra situationer som kräver en mindre lagringsstorlek och har råd med mer tid för lagring och hämtning.

Mer information om komprimering finns i Datakomprimering.

XML_COMPRESSION

gäller för: SQL Server 2022 (16.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

Anger XML-komprimeringsalternativet för det angivna indexet som innehåller en eller flera xml- datatypskolumner. Alternativen är följande:

PÅ

Index eller angivna partitioner komprimeras med hjälp av XML-komprimering.
BORT

Index eller angivna partitioner komprimeras inte med XML-komprimering.

PÅ PARTITIONER ( { <partition_number_expression> | <intervall> } [ ,...n ] )

Anger de partitioner som inställningarna för DATA_COMPRESSION eller XML_COMPRESSION gäller för. Om indexet inte är partitionerat genererar argumentet ON PARTITIONS ett fel. Om ON PARTITIONS-satsen inte tillhandahålls gäller alternativet DATA_COMPRESSION eller XML_COMPRESSION för alla partitioner i ett partitionerat index.

<partition_number_expression> kan anges på följande sätt:

Ange numret för en partition, till exempel: ON PARTITIONS (2).
Ange partitionsnumren för flera enskilda partitioner avgränsade med kommatecken, till exempel: ON PARTITIONS (1, 5).
Ange både intervall och enskilda partitioner, till exempel: ON PARTITIONS (2, 4, 6 TO 8).

<range> kan anges som partitionsnummer avgränsade med nyckelordet TO, till exempel: ON PARTITIONS (6 TO 8).

Om du vill ange olika typer av datakomprimering för olika partitioner anger du alternativet DATA_COMPRESSION mer än en gång, till exempel:

REBUILD WITH
(
DATA_COMPRESSION = NONE ON PARTITIONS (1),
DATA_COMPRESSION = ROW ON PARTITIONS (2, 4, 6 TO 8),
DATA_COMPRESSION = PAGE ON PARTITIONS (3, 5)
);

Du kan också ange alternativet XML_COMPRESSION mer än en gång, till exempel:

REBUILD WITH
(
XML_COMPRESSION = OFF ON PARTITIONS (1),
XML_COMPRESSION = ON ON PARTITIONS (2, 4, 6 TO 8),
XML_COMPRESSION = OFF ON PARTITIONS (3, 5)
);

Anmärkningar

När du skapar frågeplanen för -instruktionen CREATE INDEX kan frågeoptimeraren välja att söka igenom ett annat index i stället för att utföra en tabellgenomsökning. Sorteringsåtgärden kan elimineras i vissa situationer. På datorer CREATE INDEX med flera processorer kan du använda parallellitet för genomsöknings- och sorteringsåtgärder som är associerade med att skapa indexet, på samma sätt som andra frågor gör. Mer information finns i Konfigurera parallella indexåtgärder.

Åtgärden CREATE INDEX kan vara minimalt loggad om databasåterställningsmodellen är inställd på antingen massloggad eller enkel.

Index kan skapas i en tillfällig tabell. När tabellen tas bort eller hamnar utanför omfånget tas indexen bort.

Ett klustrat index bygger på en tabellvariabel när en primärnyckelbegränsning läggs till. På samma sätt bygger ett icke-grupperat index på en tabellvariabel när en unik begränsning läggs till. När tabellvariabeln hamnar utanför omfånget tas indexen bort.

Index stöder utökade egenskaper.

CREATE INDEX stöds inte i Microsoft Fabric.

Klustrade index

Om du skapar ett klustrade index i en tabell (heap) eller släpper och återskapar ett befintligt klustrat index måste ytterligare arbetsyta vara tillgänglig i databasen för datasortering och en tillfällig kopia av den ursprungliga tabellen eller befintliga klustrade indexdata. Mer information om klustrade index finns i Skapa klustrade index och arkitektur och designguide för SQL Server-index.

Icke-grupperade index

Från och med SQL Server 2016 (13.x), i Azure SQL Database och i Azure SQL Managed Instance kan du skapa ett icke-grupperat index i en tabell som lagras som ett grupperat kolumnlagringsindex. Om du först skapar ett icke-grupperat index i en tabell som lagras som ett heap- eller klustrade index bevaras indexet om du senare konverterar tabellen till ett grupperat kolumnlagringsindex. Det är inte heller nödvändigt att släppa det icke-illustrerade indexet när du återskapar det klustrade kolumnlagringsindexet.

Alternativet FILESTREAM_ON är inte giltigt när du skapar ett icke-grupperat index i en tabell som lagras som ett grupperat kolumnlagringsindex.

Unika index

När det finns ett unikt index söker databasmotorn efter dubblettvärden varje gång data läggs till eller ändras. Åtgärder som genererar duplicerade nyckelvärden återställs och databasmotorn returnerar ett felmeddelande. Detta gäller även om datatillägget eller ändringsåtgärden ändrar många rader men bara orsakar en dubblett. Om ett försök görs att infoga rader när det finns ett unikt index med IGNORE_DUP_KEY alternativet inställt på ONignoreras raderna som bryter mot det unika indexet.

Partitionerade index

Partitionerade index skapas och underhålls på ett liknande sätt som partitionerade tabeller, men precis som vanliga index hanteras de som separata databasobjekt. Du kan ha ett partitionerat index i en tabell som inte är partitionerad och du kan ha ett icke-partitionerat index i en tabell som är partitionerad.

Om du skapar ett index i en partitionerad tabell och inte anger en filgrupp som indexet ska placeras på partitioneras indexet på samma sätt som den underliggande tabellen. Det beror på att index som standard placeras i samma filgrupper som deras underliggande tabeller och för en partitionerad tabell i samma partitionsschema som använder samma partitioneringskolumner. När indexet använder samma partitionsschema och partitioneringskolumn som tabellen justeras indexet med tabellen.

Varning

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. Vi rekommenderar att du endast använder justerade index när antalet partitioner överskrider 1 000.

När du partitionerar ett icke-unikt grupperat index lägger databasmotorn som standard till alla partitioneringskolumner i listan över klustrade indexnycklar, om de inte redan har angetts.

Indexerade vyer kan skapas på partitionerade tabeller på samma sätt som index i tabeller. Mer information om partitionerade index finns i Partitionerade tabeller och index samt arkitektur och designguide för SQL Server-index.

När ett index skapas eller återskapas optimerar frågan uppdateringsstatistiken för indexet. För ett partitionerat index använder frågeoptimeraren standardsamplingsalgoritmen i stället för att söka igenom alla rader i tabellen efter ett icke-partitionerat index. 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.

Filtrerade index

Ett filtrerat index är ett optimerat icke-grupperat index som passar för frågor som väljer en liten procentandel rader från en tabell. Den använder ett filterpredikat för att indexera en del av data i tabellen. Ett väldesignat filtrerat index kan förbättra frågeprestanda, minska lagringskostnaderna och minska underhållskostnaderna.

Obligatoriska SET-alternativ för filtrerade index

Alternativen SET i kolumnen Obligatoriskt värde krävs när något av följande villkor inträffar:

Du skapar ett filtrerat index.
En INSERTinstruktion , UPDATE, DELETEeller MERGE ändrar data i ett filtrerat index.

Det filtrerade indexet används av frågeoptimeraren för att skapa frågeplanen.

`SET` alternativ	Obligatoriskt värde	Standardservervärde	Standardvärde för OLE DB och ODBC	Standardvärde för DB-Library
`ANSI_NULLS`	`ON`	`ON`	`ON`	`OFF`
`ANSI_PADDING`	`ON`	`ON`	`ON`	`OFF`
`ANSI_WARNINGS` ¹	`ON`	`ON`	`ON`	`OFF`
`ARITHABORT`	`ON`	`ON`	`OFF`	`OFF`
`CONCAT_NULL_YIELDS_NULL`	`ON`	`ON`	`ON`	`OFF`
`NUMERIC_ROUNDABORT`	`OFF`	`OFF`	`OFF`	`OFF`
`QUOTED_IDENTIFIER`	`ON`	`ON`	`ON`	`OFF`

¹ Inställningen ANSI_WARNINGS anges implicit ARITHABORT till ONON när databaskompatibilitetsnivån är inställd på 90 eller högre. Om databaskompatibilitetsnivån är inställd på 80 eller tidigare ARITHABORT måste alternativet uttryckligen anges till ON.

Om alternativen SET är felaktiga kan följande villkor inträffa:

Det går inte att skapa det filtrerade indexet.
Databasmotorn genererar ett fel och återställer instruktionen INSERT, UPDATE, DELETEeller MERGE som ändrar data i indexet.
Frågeoptimeraren tar inte hänsyn till indexet i körningsplanen för några Transact-SQL-instruktioner.

Mer information om filtrerade index finns i Skapa filtrerade index och arkitektur och designguide för SQL Server-index.

Rumsliga index

Information om rumsliga index finns i Översikt över CREATE SPATIAL INDEX och Spatial index.

XML-index

Information om XML-index finns i CREATE XML INDEX and XML Indexes (SQL Server).

Indexnyckelstorlek

Den maximala storleken för en indexnyckel är 900 byte för ett klustrat index och 1 700 byte för ett icke-grupperat index. (Före SQL Database och SQL Server 2016 (13.x) var gränsen alltid 900 byte.) Index för varchar-kolumner som överskrider bytegränsen kan skapas om befintliga data i kolumnerna inte överskrider gränsen när indexet skapas. Efterföljande infognings- eller uppdateringsåtgärder på kolumnerna som gör att den totala storleken blir större än gränsen misslyckas. Indexnyckeln för ett grupperat index får inte innehålla varchar kolumner som har befintliga data i ROW_OVERFLOW_DATA allokeringsenhet. Om ett klustrat index skapas i en varchar-kolumn och befintliga data finns i IN_ROW_DATA allokeringsenheten misslyckas efterföljande infognings- eller uppdateringsåtgärder i kolumnen som skulle skicka data från rad.

Icke-grupperade index kan innehålla icke-nyckelkolumner (ingår) i indexets lövnivå. Dessa kolumner beaktas inte av databasmotorn vid beräkning av indexnyckelns storlek. Mer information finns i Skapa index med inkluderade kolumner och arkitektur och designguide för SQL Server-index.

Not

Om partitioneringsnyckelkolumnerna inte redan finns i ett icke-unikt grupperat index läggs de till i indexet av databasmotorn när tabellerna partitioneras. Den kombinerade storleken på de indexerade kolumnerna (räknar inte inkluderade kolumner), plus eventuella tillagda partitioneringskolumner får inte överstiga 1 800 byte i ett icke-unikt grupperat index.

Beräknade kolumner

Index kan skapas på beräknade kolumner. Dessutom kan beräknade kolumner ha egenskapen PERSISTED. Det innebär att databasmotorn lagrar de beräknade värdena i tabellen och uppdaterar dem när andra kolumner som den beräknade kolumnen är beroende av uppdateras på. Databasmotorn använder dessa bevarade värden när det skapar ett index i kolumnen och när indexet refereras i en fråga.

Om du vill indexera en beräknad kolumn måste den beräknade kolumnen vara deterministisk och exakt. Men om du använder PERSISTED egenskapen expanderas typen av indexerbara beräknade kolumner till att omfatta:

Beräknade kolumner baserade på Transact-SQL- och CLR-funktioner och CLR-användardefinierade typmetoder som markeras som deterministiska av användaren.
Beräknade kolumner baserade på uttryck som är deterministiska enligt definitionen av databasmotorn men oprecisa.

Beständiga beräknade kolumner kräver att följande SET alternativ anges enligt föregående avsnitt Obligatoriska SET-alternativ för filtrerade index.

Villkoret UNIQUE eller PRIMARY KEY kan innehålla en beräknad kolumn så länge den uppfyller alla villkor för indexering. Mer specifikt måste den beräknade kolumnen vara deterministisk och exakt eller deterministisk och bevarad. Mer information om determinism finns i Deterministiska och nondeterministiska funktioner.

Beräknade kolumner som härletts från bild, ntext, text, varchar(max), nvarchar(max), varbinary(max), och XML- datatyper kan indexeras antingen som en nyckel eller inkluderad icke-nyckelkolumn så länge datatypen för den beräknade kolumnen är tillåten som en indexnyckelkolumn eller icke-nyckelkolumn. Du kan till exempel inte skapa ett primärt XML-index på en beräknad xml- kolumn. Om indexnyckelns storlek överskrider 900 byte visas ett varningsmeddelande.

Om du skapar ett index i en beräknad kolumn kan det orsaka fel i en infognings- eller uppdateringsåtgärd som tidigare fungerade. Ett sådant fel kan inträffa när den beräknade kolumnen resulterar i ett aritmetikfel.

Till exempel i följande tabell, även om uttrycket för den beräknade kolumnen c verkar resultera i ett aritmetikfel när raden infogas, fungerar -instruktionen INSERT .

CREATE TABLE t1 (a INT, b INT, c AS a/b);
INSERT INTO t1 VALUES (1, 0);

Men om du skapar ett index för den beräknade kolumnen cmisslyckas samma INSERT instruktion.

CREATE TABLE t1 (a INT, b INT, c AS a/b);
CREATE UNIQUE CLUSTERED INDEX Idx1 ON t1(c);
INSERT INTO t1 VALUES (1, 0);

Mer information finns i Index över beräknade kolumner.

Inkluderade kolumner i index

Icke-nyckelkolumner, som kallas inkluderade kolumner, kan läggas till på lövnivån för ett icke-grupperat index för att förbättra frågeprestandan genom att täcka frågan. Det betyder att alla kolumner som refereras i frågan ingår i indexet som antingen nyckelkolumner eller icke-nyckelkolumner. På så sätt kan frågeoptimeraren hämta all nödvändig information från en icke-illustrerad indexgenomsökning eller sökning. tabell- eller klustrade indexdata används inte. Mer information finns i Skapa index med inkluderade kolumner och arkitektur och designguide för SQL Server-index.

Ange indexalternativ

SQL Server 2005 (9.x) introducerade nya indexalternativ och ändrade även hur alternativ anges. I den bakåtkompatibla syntaxen WITH option_name motsvarar WITH (option_name = ON). När du anger indexalternativ gäller följande regler:

Nya indexalternativ kan bara anges med hjälp av WITH (<option_name> = <ON | OFF>).
Alternativ kan inte anges med både bakåtkompatibel och ny syntax i samma instruktion. Om du till exempel anger WITH (DROP_EXISTING, ONLINE = ON) misslyckas instruktionen.
När du skapar ett XML-index måste alternativen anges med hjälp av WITH (<option_name> = <ON | OFF>).

DROP_EXISTING-sats

Du kan använda satsen DROP_EXISTING för att återskapa indexet, lägga till eller släppa kolumner, ändra alternativ, ändra kolumnsorteringsordning eller ändra partitionsschemat eller filgruppen.

Om indexet framtvingar en PRIMARY KEY eller UNIQUE begränsning och indexdefinitionen inte ändras på något sätt, tas indexet bort och skapas på nytt, vilket bevarar den befintliga begränsningen. Men om indexdefinitionen ändras misslyckas -instruktionen. Om du vill ändra definitionen av en PRIMARY KEY eller UNIQUE -begränsningen släpper du villkoret och lägger till en begränsning med den nya definitionen.

DROP_EXISTING förbättrar prestandan när du återskapar ett klustrat index, med antingen samma eller en annan uppsättning nycklar, i en tabell som också har icke-grupperade index. DROP_EXISTING ersätter körningen av en DROP INDEX-instruktion för det gamla klustrade indexet följt av körningen av en CREATE INDEX-instruktion för det nya klustrade indexet. De icke-grupperade indexen återskapas en gång och sedan bara om indexdefinitionen har ändrats. Satsen DROP_EXISTING återskapar inte de icke-illustrerade indexen när indexdefinitionen har samma indexnamn, nyckel- och partitionskolumner, unika attribut och sorteringsordning som det ursprungliga indexet.

Oavsett om de icke-grupperade indexen återskapas eller inte finns de alltid kvar i sina ursprungliga filgrupper eller partitionsscheman och använder de ursprungliga partitionsfunktionerna. Om ett klustrat index återskapas till ett annat filgrupps- eller partitionsschema flyttas inte de icke-grupperade indexen för att sammanfalla med den nya platsen för det klustrade indexet. Även om de icke-grupperade indexen tidigare var justerade med det klustrade indexet kanske de inte längre är i linje med det. Mer information om partitionerad indexjustering finns i Partitionerade tabeller och index.

DROP_EXISTING Satsen sorterar inte data igen om samma indexnyckelkolumner används i samma ordning och med samma stigande eller fallande ordning, såvida inte indexsatsen anger ett icke-grupperat index och ONLINE alternativet är inställt på OFF. Om det klustrade indexet är inaktiverat CREATE INDEX WITH DROP_EXISTING måste åtgärden utföras med ONLINE värdet OFF. Om ett icke-grupperat index är inaktiverat och inte är associerat med ett inaktiverat grupperat index kan CREATE INDEX WITH DROP_EXISTING åtgärden utföras med ONLINE inställt på OFF eller ON.

Not

När index med 128 omfattningar eller mer tas bort eller återskapas, defersar databasmotorn de faktiska sidallokeringarna och deras associerade lås tills transaktionen har checkats in. Mer information finns i Uppskjuten frigöring.

ONLINE-alternativ

Följande riktlinjer gäller för att utföra indexåtgärder online:

Den underliggande tabellen kan inte ändras, trunkeras eller tas bort när en onlineindexåtgärd pågår.
Ytterligare tillfälligt diskutrymme krävs under indexåtgärden.
Onlineåtgärder kan utföras på partitionerade index och index som innehåller beständiga beräknade kolumner eller inkluderade kolumner.
Med WAIT_AT_LOW_PRIORITY argumentalternativet kan du bestämma hur indexåtgärden ska fortsätta när den väntar på ett Sch-M lås. Mer information finns i WAIT_AT_LOW_PRIORITY

Mer information finns i Utföra indexåtgärder online.

Återupptabara indexåtgärder

gäller för: SQL Server 2019 (15.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

Du kan göra en åtgärd för att skapa onlineindex återupptas. Det innebär att indexversionen kan stoppas och senare startas om från den punkt där den stoppades. Om du vill köra en indexversion som återupptabar anger du alternativet RESUMABLE = ON .

Följande riktlinjer gäller för återupptabara indexåtgärder:

Om du vill använda alternativet RESUMABLE måste du också använda alternativet ONLINE.
Alternativet RESUMABLE sparas inte i metadata för ett visst index och gäller endast varaktigheten för den aktuella DDL-instruktionen. Därför måste RESUMABLE = ON-satsen anges uttryckligen för att möjliggöra återupptagande.
Alternativet MAX_DURATION kan anges i två kontexter:
- MAX_DURATION för alternativet RESUMABLE anger tidsintervallet för ett index som återskapas. Efter den här tiden har förflutit, och om indexet återskapas fortfarande körs, pausas det. Du bestämmer när återskapande för ett pausat index kan återupptas. Den tiden i minuter för MAX_DURATION måste vara större än 0 minuter och mindre än eller lika med en vecka (7 * 24 * 60 = 10080 minuter). En lång paus i en indexåtgärd kan märkbart påverka DML-prestanda för en specifik tabell samt databasdiskkapaciteten eftersom både det ursprungliga indexet och det nyligen skapade indexet kräver diskutrymme och måste uppdateras av DML-åtgärder. Om MAX_DURATION alternativet utelämnas fortsätter indexåtgärden tills det har slutförts eller tills ett fel inträffar.
- MAX_DURATION för alternativet WAIT_AT_LOW_PRIORITY anger tiden att vänta med hjälp av lås med låg prioritet om indexåtgärden blockeras innan åtgärden vidtas. Mer information finns i WAIT_AT_LOW_PRIORITY med onlineindexåtgärder.
Om du vill pausa indexåtgärden direkt kan du köra kommandot ALTER INDEX PAUSE eller köra kommandot KILL <session_id>.
Om du kör den ursprungliga CREATE INDEX instruktionen igen med samma parametrar återupptas en pausad indexgenereringsåtgärd. Du kan också återuppta en pausad indexgenereringsåtgärd genom att köra -instruktionen ALTER INDEX RESUME .
Kommandot ABORT stoppar sessionen som kör en indexversion och avbryter indexåtgärden. Du kan inte återuppta en indexåtgärd som har avbrutits.

En återupptabar indexåtgärd körs tills den har slutförts, pausar eller misslyckas. Om åtgärden pausas utfärdas ett fel som anger att åtgärden har pausats och att indexet inte har skapats. Om åtgärden misslyckas utfärdas även ett fel.

Om du vill se om en indexåtgärd körs som en återupptabar åtgärd och kontrollera dess aktuella körningstillstånd använder du sys.index_resumable_operations katalogvyn.

Resurser

Följande resurser krävs för att återuppta indexåtgärder:

Ytterligare utrymme krävs för att behålla indexet som skapas, inklusive tiden då bygget pausas.
Ytterligare loggdataflöde under sorteringsfasen. Den totala loggutrymmesanvändningen för återupptabart index är mindre jämfört med vanlig onlineindexskapande och tillåter loggtrunkering under den här åtgärden.
DDL-instruktioner som försöker ändra tabellen som är associerad med indexet som skapas medan indexåtgärden pausas tillåts inte.
Ghost-rensning blockeras i det inbyggda indexet under åtgärdens varaktighet både när åtgärden pausas och medan åtgärden körs.
Om tabellen innehåller LOB-kolumner krävs ett schemaändringslås (Sch-M) i början av åtgärden för att kunna återuppta klustrad indexversion.

Aktuella funktionsbegränsningar

Åtgärder för att skapa index som kan återupptas har följande begränsningar:

När en återupptabar onlineindexskapandeåtgärd har pausats kan det ursprungliga värdet MAXDOP för inte ändras.
Alternativet SORT_IN_TEMPDB = ON stöds inte för återupptabara indexåtgärder.
DDL-kommandot med RESUMABLE = ON kan inte köras i en explicit transaktion.
Du kan inte skapa ett återupptabart index som innehåller:
- Beräknade eller timestamp (rowversion) kolumner som nyckelkolumner.
- LOB-kolumn som en inkluderad kolumn.
Återupptabara indexåtgärder stöds inte för:
- Kommandot ALTER INDEX REBUILD ALL
- Kommandot ALTER TABLE REBUILD
- Kolumnlagerindexar
- Filtrerade index
- Inaktiverade index

WAIT_AT_LOW_PRIORITY med onlineindexåtgärder

gäller för: SQL Server 2022 (16.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

När du inte använder WAIT_AT_LOW_PRIORITY alternativet måste alla aktiva blockerande transaktioner som innehåller lås på tabellen eller indexet slutföras för att indexskapandeåtgärden ska starta och slutföras. När onlineindexåtgärden startar och innan den slutförs måste den hämta ett delat (S) eller en schemaändring (Sch-M) låsa tabellen och hålla den under en kort tid. Även om låset endast hålls under en kort tid kan det avsevärt påverka arbetsbelastningens dataflöde, öka frågefördröjningen eller orsaka tidsgränser för körning.

För att undvika dessa problem kan du med alternativet WAIT_AT_LOW_PRIORITY hantera beteendet för S eller Sch-M lås som krävs för att en onlineindexåtgärd ska starta och slutföras och välja bland tre alternativ. Om det under den väntetid som anges av MAX_DURATION = n [minutes] inte finns någon blockering som omfattar indexåtgärden fortsätter indexåtgärden omedelbart.

WAIT_AT_LOW_PRIORITY gör att onlineindexåtgärden väntar med hjälp av lås med låg prioritet, vilket gör att andra åtgärder som använder normala prioritetslås kan fortsätta under tiden. Om du utelämnar alternativet WAIT_AT_LOW_PRIORITY motsvarar det WAIT_AT_LOW_PRIORITY (MAX_DURATION = 0 minutes, ABORT_AFTER_WAIT = NONE).

MAX_DURATION = tid [MINUTES]

Väntetiden (ett heltalsvärde som anges i minuter) som onlineindexåtgärden väntar med hjälp av lås med låg prioritet. Om åtgärden blockeras under MAX_DURATION tid körs den angivna ABORT_AFTER_WAIT åtgärden. MAX_DURATION tiden är alltid i minuter och ordet MINUTES kan utelämnas.

ABORT_AFTER_WAIT = [NONE | SELF | BLOCKERS ]

NONE: Fortsätt att vänta på låset med normal prioritet.
SELF: Avsluta den onlineindexåtgärd som körs för närvarande, utan att vidta några åtgärder. Alternativet SELF kan inte användas när MAX_DURATION är 0.
BLOCKERS: Avsluta alla användartransaktioner som blockerar onlineindexåtgärden så att åtgärden kan fortsätta. Alternativet BLOCKERS kräver att huvudkontot som kör CREATE INDEX- eller ALTER INDEX-instruktionen har ALTER ANY CONNECTION behörighet.

Du kan använda följande utökade händelser för att övervaka indexåtgärder som väntar på lås med låg prioritet:

lock_request_priority_state
process_killed_by_abort_blockers
ddl_with_wait_at_low_priority

Alternativ för rad- och sidlås

När ALLOW_ROW_LOCKS = ON och ALLOW_PAGE_LOCK = ONtillåts rad-, sid- och tabellnivålås vid åtkomst till indexet. Databasmotorn väljer lämpligt lås och kan eskalera låset från ett rad- eller sidlås till ett tabelllås.

När ALLOW_ROW_LOCKS = OFF och ALLOW_PAGE_LOCK = OFFtillåts endast ett lås på tabellnivå vid åtkomst till indexet.

Varning

Vi rekommenderar inte att du inaktiverar rad- eller sidlås på ett index. Samtidighetsrelaterade problem kan uppstå och vissa funktioner kan vara otillgängliga. Ett index kan till exempel inte ordnas om när ALLOW_PAGE_LOCKS är inställt på OFF.

Sekventiella nycklar

Gäller för: SQL Server 2019 (15.x) och senare versioner, i Azure SQL Database och i Azure SQL Managed Instance.

Konkurrens vid infogning på sista sidan är ett vanligt prestandaproblem som uppstår när ett stort antal samtidiga trådar försöker infoga rader i ett index med en sekventiell nyckel. Ett index betraktas som sekventiellt när den inledande nyckelkolumnen innehåller värden som alltid ökar (eller minskar), till exempel en identitetskolumn eller ett datum som är standard för aktuellt datum/tid. Eftersom nycklarna som infogas är sekventiella infogas alla nya rader i slutet av indexstrukturen , med andra ord på samma sida. Detta leder till konkurrens om sidan i minnet som kan observeras som flera trådar som väntar på att hämta en spärr för sidan i fråga. Motsvarande väntetyp är PAGELATCH_EX.

Om du aktiverar alternativet OPTIMIZE_FOR_SEQUENTIAL_KEY index kan du optimera databasmotorn som hjälper till att förbättra dataflödet för infogningar med hög samtidighet i indexet. Den är avsedd för index som har en sekventiell nyckel och därmed är benägna att infoga konkurrens på sista sidan, men det kan också hjälpa till med index som har hot spots i andra områden i B-Tree-indexstrukturen.

Not

Datakomprimering

Mer information om datakomprimering finns i Datakomprimering.

Följande är de viktigaste punkterna att tänka på i samband med indexgenereringsåtgärder när datakomprimering används:

Komprimering kan tillåta att fler rader lagras på en sida, men ändrar inte den maximala radstorleken.
Icke-lövsidor i ett index är inte sidkomprimerade utan kan radkomprimeras.
Varje icke-grupperat index har en individuell komprimeringsinställning och ärver inte komprimeringsinställningen för den underliggande tabellen.
När ett klustrat index skapas på en heap ärver det klustrade indexet heapens komprimeringstillstånd om inte ett alternativt komprimeringstillstånd anges.

Om du vill utvärdera hur ändring av komprimeringstillståndet påverkar utrymmesanvändningen av en tabell, ett index eller en partition använder du den sp_estimate_data_compression_savings lagrade proceduren.

XML-komprimering

gäller för: SQL Server 2022 (16.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance.

Många av övervägandena för datakomprimering gäller XML-komprimering. Du bör också vara medveten om följande överväganden:

När en lista över partitioner har angetts kan XML-komprimering aktiveras på enskilda partitioner. Om listan över partitioner inte har angetts är alla partitioner inställda på att använda XML-komprimering. När en tabell eller ett index skapas inaktiveras XML-datakomprimering om inget annat anges. När en tabell ändras bevaras den befintliga komprimering om inget annat anges.
Om du anger en lista över partitioner eller en partition som ligger utom räckhåll genereras ett fel.
När ett klustrat index skapas på en heap ärver det klustrade indexet heapens XML-komprimeringstillstånd om inte ett alternativt komprimeringsalternativ har angetts.
Om du ändrar XML-komprimeringsinställningen för en heap måste alla icke-illustrerade index i tabellen återskapas så att de har pekare till de nya radplatserna i heapen.
Du kan aktivera eller inaktivera XML-komprimering online eller offline. Aktivering av komprimering på en heap är en tråd för en onlineåtgärd.
Om du vill fastställa XML-komprimeringstillståndet för partitioner i en partitionerad tabell använder du xml_compression kolumnen i sys.partitions katalogvyn.

Indexstatistik

När ett radlagringsindex skapas skapar databasmotorn även statistik över nyckelkolumnerna i indexet. Namnet på statistikobjektet i katalogvyn sys.stats matchar indexets namn. För ett icke-partitionerat index skapas statistiken med en fullständig genomsökning av data. För ett partitionerat index skapas statistik med hjälp av standardsamplingsalgoritmen.

När ett kolumnlagringsindex skapas skapar databasmotorn även ett statistikobjekt i sys.stats . Det här statistikobjektet innehåller inte statistikdata som histogrammet och densitetsvektorn. Den används när du skapar en databasklon genom att skripta databasen. Vid den tidpunkten DBCC SHOW_STATISTICS används kommandona och UPDATE STATISTICS ... WITH STATS_STREAM för att hämta kolumnlagringsmetadata som segment, ordlista och deltalagringsstorlek och lägga till dem i statistiken för kolumnlagringsindexet. Dessa metadata hämtas dynamiskt vid frågekompilering för en vanlig databas, men tillhandahålls av statistikobjektet för en databasklon. Kommandot UPDATE STATISTICS stöds inte för statistikobjektet i ett columnstore-index i något annat scenario.

Behörigheter

Kräver behörighet för ALTER tabellen eller vyn eller medlemskapet i den fasta databasrollen db_ddladmin .

Begränsningar och begränsningar

I Azure Synapse Analytics and Analytics Platform System (PDW) kan du inte skapa:

Ett grupperat eller icke-grupperat radlagringsindex i en informationslagertabell när det redan finns ett kolumnlagringsindex. Det här beteendet skiljer sig från SMP SQL Server som gör att både rowstore- och columnstore-index kan samexistera i samma tabell.
Du kan inte skapa ett index i en vy.

Metadata

Om du vill visa information om befintliga index kan du fråga sys.indexes katalogvy.

Versionsanteckningar

Azure SQL Database stöder inte andra filgrupper än PRIMARY.
Azure SQL Database och Azure SQL Managed Instance stöder inte FILESTREAM alternativ.
Kolumnlagringsindex är inte tillgängliga före SQL Server 2012 (11.x).
Återupptabara indexåtgärder är tillgängliga från och med SQL Server 2017 (14.x), i Azure SQL Database och i Azure SQL Managed Instance.

Exempel: Alla versioner. Använder AdventureWorks-databasen

A. Skapa ett enkelt icke-grupperat radlagringsindex

I följande exempel skapas ett icke-grupperat index i kolumnen VendorID i tabellen Purchasing.ProductVendor.

CREATE INDEX IX_VendorID ON ProductVendor (VendorID);
CREATE INDEX IX_VendorID ON dbo.ProductVendor (VendorID DESC, Name ASC, Address DESC);
CREATE INDEX IX_VendorID ON Purchasing..ProductVendor (VendorID);

B. Skapa ett enkelt sammansatt rowstore-index som inte visas

I följande exempel skapas ett icke-grupperat sammansatt index i kolumnerna SalesQuota och SalesYTD i tabellen Sales.SalesPerson.

CREATE NONCLUSTERED INDEX IX_SalesPerson_SalesQuota_SalesYTD ON Sales.SalesPerson (SalesQuota, SalesYTD);

C. Skapa ett index i en tabell i en annan databas

I följande exempel skapas ett grupperat index i kolumnen VendorID i tabellen ProductVendor i databasen Purchasing.

CREATE CLUSTERED INDEX IX_ProductVendor_VendorID ON Purchasing..ProductVendor (VendorID);

D. Lägga till en kolumn i ett index

I följande exempel skapas index IX_FF med två kolumner från dbo. FactFinance-tabell. Nästa instruktion återskapar indexet med ytterligare en kolumn och behåller det befintliga namnet.

CREATE INDEX IX_FF ON dbo.FactFinance (FinanceKey ASC, DateKey ASC);

-- Rebuild and add the OrganizationKey
CREATE INDEX IX_FF ON dbo.FactFinance (FinanceKey, DateKey, OrganizationKey DESC)
  WITH (DROP_EXISTING = ON);

Exempel: SQL Server, Azure SQL Database

E. Skapa ett unikt icke-grupperat index

I följande exempel skapas ett unikt icke-illustrerat index i kolumnen Name i Production.UnitMeasure-tabellen i AdventureWorks2022-databasen. Indexet framtvingar unikhet för data som infogas i kolumnen Name.

CREATE UNIQUE INDEX AK_UnitMeasure_Name
  ON Production.UnitMeasure(Name);

Följande fråga testar unikhetsbegränsningen genom att försöka infoga en rad med samma värde som i en befintlig rad.

-- Verify the existing value.
SELECT Name FROM Production.UnitMeasure WHERE Name = N'Ounces';
GO

INSERT INTO Production.UnitMeasure (UnitMeasureCode, Name, ModifiedDate)
  VALUES ('OC', 'Ounces', GETDATE());

Det resulterande felmeddelandet är:

Server: Msg 2601, Level 14, State 1, Line 1
Cannot insert duplicate key row in object 'UnitMeasure' with unique index 'AK_UnitMeasure_Name'. The statement has been terminated.

F. Använd alternativet IGNORE_DUP_KEY

I följande exempel visas effekten av alternativet IGNORE_DUP_KEY genom att infoga flera rader i en tillfällig tabell först med alternativet inställt på ON och igen med alternativet inställt på OFF. En enskild rad infogas i tabellen #Test som avsiktligt orsakar ett duplicerat värde när den andra instruktionen för flera rader INSERT körs. Antalet rader i tabellen returnerar antalet infogade rader.

CREATE TABLE #Test (C1 NVARCHAR(10), C2 NVARCHAR(50), C3 DATETIME);
GO

CREATE UNIQUE INDEX AK_Index ON #Test (C2)
  WITH (IGNORE_DUP_KEY = ON);
GO

INSERT INTO #Test VALUES (N'OC', N'Ounces', GETDATE());
INSERT INTO #Test SELECT * FROM Production.UnitMeasure;
GO

SELECT COUNT(*) AS [Number of rows] FROM #Test;
GO

DROP TABLE #Test;
GO

Här är resultatet av den andra INSERT-instruktionen.

Server: Msg 3604, Level 16, State 1, Line 5 Duplicate key was ignored.

Number of rows
--------------
38

Observera att de rader som infogats från tabellen Production.UnitMeasure som inte bröt mot unikhetsbegränsningen har infogats. En varning utfärdades och dubblettraden ignorerades, men hela transaktionen återställdes inte.

Samma instruktioner körs igen, men med IGNORE_DUP_KEY inställt på OFF.

CREATE TABLE #Test (C1 NVARCHAR(10), C2 NVARCHAR(50), C3 DATETIME);
GO

CREATE UNIQUE INDEX AK_Index ON #Test (C2)
  WITH (IGNORE_DUP_KEY = OFF);
GO

INSERT INTO #Test VALUES (N'OC', N'Ounces', GETDATE());
INSERT INTO #Test SELECT * FROM Production.UnitMeasure;
GO

SELECT COUNT(*) AS [Number of rows] FROM #Test;
GO

DROP TABLE #Test;
GO

Här är resultatet av den andra INSERT-instruktionen.

Server: Msg 2601, Level 14, State 1, Line 5
Cannot insert duplicate key row in object '#Test' with unique index
'AK_Index'. The statement has been terminated.

Number of rows
--------------
1

Observera att ingen av raderna från den Production.UnitMeasure tabellen infogades i tabellen trots att endast en rad i tabellen bröt mot UNIQUE indexvillkor.

G. Använda DROP_EXISTING för att släppa och återskapa ett index

I följande exempel släpps och återskapas ett befintligt index i kolumnen ProductID i tabellen Production.WorkOrder i AdventureWorks2022-databasen med hjälp av alternativet DROP_EXISTING. Alternativen FILLFACTOR och PAD_INDEX anges också.

CREATE NONCLUSTERED INDEX IX_WorkOrder_ProductID
  ON Production.WorkOrder(ProductID)
    WITH (FILLFACTOR = 80,
      PAD_INDEX = ON,
      DROP_EXISTING = ON);
GO

H. Skapa ett index i en vy

I följande exempel skapas en vy och ett index för den vyn. Två frågor ingår som använder den indexerade vyn.

-- Set the options to support indexed views
SET NUMERIC_ROUNDABORT OFF;
SET ANSI_PADDING, ANSI_WARNINGS, CONCAT_NULL_YIELDS_NULL, ARITHABORT,
  QUOTED_IDENTIFIER, ANSI_NULLS ON;
GO

-- Create view with schemabinding
IF OBJECT_ID ('Sales.vOrders', 'view') IS NOT NULL
  DROP VIEW Sales.vOrders;
GO

CREATE VIEW Sales.vOrders
  WITH SCHEMABINDING
AS
  SELECT SUM(UnitPrice * OrderQty * (1.00 - UnitPriceDiscount)) AS Revenue,
    OrderDate, ProductID, COUNT_BIG(*) AS COUNT
  FROM Sales.SalesOrderDetail AS od, Sales.SalesOrderHeader AS o
  WHERE od.SalesOrderID = o.SalesOrderID
  GROUP BY OrderDate, ProductID;
GO

-- Create an index on the view
CREATE UNIQUE CLUSTERED INDEX IDX_V1
  ON Sales.vOrders (OrderDate, ProductID);
GO

-- This query can use the indexed view even though the view is
-- not specified in the FROM clause.
SELECT SUM(UnitPrice * OrderQty * (1.00 - UnitPriceDiscount)) AS Rev,
  OrderDate, ProductID
FROM Sales.SalesOrderDetail AS od
  JOIN Sales.SalesOrderHeader AS o ON od.SalesOrderID = o.SalesOrderID
    AND ProductID BETWEEN 700 AND 800
    AND OrderDate >= CONVERT(DATETIME, '05/01/2002', 101)
GROUP BY OrderDate, ProductID
ORDER BY Rev DESC;
GO

-- This query can use the above indexed view
SELECT OrderDate, SUM(UnitPrice * OrderQty * (1.00 - UnitPriceDiscount)) AS Rev
FROM Sales.SalesOrderDetail AS od
  JOIN Sales.SalesOrderHeader AS o ON od.SalesOrderID = o.SalesOrderID
    AND DATEPART(mm, OrderDate) = 3
  AND DATEPART(yy, OrderDate) = 2002
GROUP BY OrderDate
ORDER BY OrderDate ASC;
GO

Jag. Skapa ett index med inkluderade kolumner (icke-nyckel)

I följande exempel skapas ett icke-grupperat index med en nyckelkolumn (PostalCode) och fyra icke-nyckelkolumner (AddressLine1, AddressLine2, City, StateProvinceID). En fråga som omfattas av indexet följer. Om du vill visa det index som har valts av frågeoptimeraren går du till menyn Query i SQL Server Management Studio och väljer Visa verklig körningsplan innan du kör frågan.

CREATE NONCLUSTERED INDEX IX_Address_PostalCode
  ON Person.Address (PostalCode)
  INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);
GO

SELECT AddressLine1, AddressLine2, City, StateProvinceID, PostalCode
FROM Person.Address
WHERE PostalCode BETWEEN N'98000' and N'99999';
GO

J. Skapa ett partitionerat index

I följande exempel skapas ett icke-grupperat partitionerat index på TransactionsPS1, ett befintligt partitionsschema i AdventureWorks2022-databasen. Det här exemplet förutsätter att det partitionerade indexexemplet har installerats.

CREATE NONCLUSTERED INDEX IX_TransactionHistory_ReferenceOrderID
  ON Production.TransactionHistory (ReferenceOrderID)
  ON TransactionsPS1 (TransactionDate);
GO

K. Skapa ett filtrerat index

I följande exempel skapas ett filtrerat index i tabellen Production.BillOfMaterials i databasen AdventureWorks2022. Filterpredikatet kan innehålla kolumner som inte är nyckelkolumner i det filtrerade indexet. Predikatet i det här exemplet väljer endast de rader där EndDate inte är NULL.

CREATE NONCLUSTERED INDEX "FIBillOfMaterialsWithEndDate"
  ON Production.BillOfMaterials (ComponentID, StartDate)
  WHERE EndDate IS NOT NULL;

L. Skapa ett komprimerat index

I följande exempel skapas ett index i en icke-partitionerad tabell med hjälp av radkomprimering.

CREATE NONCLUSTERED INDEX IX_INDEX_1
  ON T1 (C2)
  WITH (DATA_COMPRESSION = ROW);
GO

I följande exempel skapas ett index i en partitionerad tabell med hjälp av radkomprimering på alla partitioner i indexet.

CREATE CLUSTERED INDEX IX_PartTab2Col1
  ON PartitionTable1 (Col1)
  WITH (DATA_COMPRESSION = ROW);
GO

I följande exempel skapas ett index i en partitionerad tabell med hjälp av sidkomprimering på partition 1 av index- och radkomprimering på partitioner 2 via 4 av indexet.

CREATE CLUSTERED INDEX IX_PartTab2Col1
  ON PartitionTable1 (Col1)
  WITH (
    DATA_COMPRESSION = PAGE ON PARTITIONS(1),
    DATA_COMPRESSION = ROW ON PARTITIONS (2 TO 4)
  );
GO

M. Skapa ett index med XML-komprimering

gäller för: SQL Server 2022 (16.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance.

I följande exempel skapas ett index i en icke-partitionerad tabell med hjälp av XML-komprimering. Minst en kolumn i indexet måste vara xml- datatyp.

CREATE NONCLUSTERED INDEX IX_INDEX_1
  ON T1 (C2)
  WITH (XML_COMPRESSION = ON);
GO

I följande exempel skapas ett index i en partitionerad tabell med hjälp av XML-komprimering på alla partitioner i indexet.

CREATE CLUSTERED INDEX IX_PartTab2Col1
  ON PartitionTable1 (Col1)
  WITH (XML_COMPRESSION = ON);
GO

N. Skapa, återuppta, pausa och avbryta återupptabara indexåtgärder

gäller för: SQL Server 2019 (15.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

-- Execute a resumable online index create statement with MAXDOP=1
CREATE INDEX test_idx1 ON test_table (col1) WITH (ONLINE = ON, MAXDOP = 1, RESUMABLE = ON);

-- Executing the same command again (see above) after an index operation was paused, resumes automatically the index create operation.

-- Execute a resumable online index creates operation with MAX_DURATION set to 240 minutes. After the time expires, the resumable index create operation is paused.
CREATE INDEX test_idx2 ON test_table (col2) WITH (ONLINE = ON, RESUMABLE = ON, MAX_DURATION = 240);

-- Pause a running resumable online index creation
ALTER INDEX test_idx1 ON test_table PAUSE;
ALTER INDEX test_idx2 ON test_table PAUSE;

-- Resume a paused online index creation
ALTER INDEX test_idx1 ON test_table RESUME;
ALTER INDEX test_idx2 ON test_table RESUME;

-- Abort resumable index create operation which is running or paused
ALTER INDEX test_idx1 ON test_table ABORT;
ALTER INDEX test_idx2 ON test_table ABORT;

O. SKAPA INDEX med olika låsalternativ med låg prioritet

I följande exempel används alternativet WAIT_AT_LOW_PRIORITY för att ange olika strategier för att hantera blockering.

--Kill this session after waiting 5 minutes
CREATE CLUSTERED INDEX idx_1 ON dbo.T2 (a) WITH (ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = SELF)));
GO

--Kill blocker sessions
CREATE CLUSTERED INDEX idx_1 ON dbo.T2 (a) WITH (ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = BLOCKERS)));
GO

I följande exempel används både alternativet RESUMABLE och två MAX_DURATION värden, det första gäller för alternativet ABORT_AFTER_WAIT, det andra gäller för alternativet RESUMABLE.

--With resumable option; default locking behavior 
CREATE CLUSTERED INDEX idx_1 ON dbo.T2 (a) WITH (ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = NONE)), RESUMABLE = ON, MAX_DURATION = 240 MINUTES);

Exempel: Azure Synapse Analytics and Analytics Platform System (PDW)

P. Grundläggande syntax

Skapa, återuppta, pausa och avbryta återupptabara indexåtgärder

gäller för: SQL Server 2019 (15.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance

-- Execute a resumable online index create statement with MAXDOP=1
CREATE INDEX test_idx ON test_table WITH (ONLINE = ON, MAXDOP = 1, RESUMABLE = ON);

-- Executing the same command again (see above) after an index operation was paused, resumes automatically the index create operation.

-- Execute a resumable online index creates operation with MAX_DURATION set to 240 minutes. After the time expires, the resumable index create operation is paused.
CREATE INDEX test_idx ON test_table WITH (ONLINE = ON, RESUMABLE = ON, MAX_DURATION = 240);

-- Pause a running resumable online index creation
ALTER INDEX test_idx ON test_table PAUSE;

-- Resume a paused online index creation
ALTER INDEX test_idx ON test_table RESUME;

-- Abort resumable index create operation which is running or paused
ALTER INDEX test_idx ON test_table ABORT;

Q. Skapa ett icke-grupperat index i en tabell i den aktuella databasen

I följande exempel skapas ett icke-grupperat index i kolumnen VendorID i tabellen ProductVendor.

CREATE INDEX IX_ProductVendor_VendorID
  ON ProductVendor (VendorID);

R. Skapa ett grupperat index i en tabell i en annan databas

I följande exempel skapas ett icke-grupperat index i kolumnen VendorID i tabellen ProductVendor i databasen Purchasing.

CREATE CLUSTERED INDEX IX_ProductVendor_VendorID
  ON Purchasing..ProductVendor (VendorID);

S. Skapa ett ordnat grupperat index i en tabell

I följande exempel skapas ett ordnat grupperat index på kolumnerna c1 och c2 i tabellen T1 i MyDB-databasen.

CREATE CLUSTERED COLUMNSTORE INDEX MyOrderedCCI ON MyDB.dbo.T1 
ORDER (c1, c2);

T. Konvertera en CCI till ett ordnat grupperat index i en tabell

I följande exempel konverteras det befintliga klustrade kolumnlagringsindexet till ett ordnat grupperat kolumnlagringsindex med namnet MyOrderedCCI i kolumnerna c1 och c2 i T2-tabellen i MyDB-databasen.

CREATE CLUSTERED COLUMNSTORE INDEX MyOrderedCCI ON MyDB.dbo.T2
ORDER (c1, c2)
WITH (DROP_EXISTING = ON);

Dela via

SKAPA INDEX (Transact-SQL)

Syntax

Syntax för SQL Server, Azure SQL Database, Azure SQL Managed Instance

Bakåtkompatibelt relationsindex

Syntax för Azure Synapse Analytics och Parallel Data Warehouse

Argument

UNIK

KLUSTRADE

NONCLUSTERED

index_name

kolumn

[ ASC | DESC ]

INCLUDE (column [ ,... n ] )

VAR <filter_predicate>

PÅ partition_scheme_name ( column_name )

PÅ filegroup_name

PÅ [standard]

[ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]

<objekt>::=

database_name

schema_name

table_or_view_name

<relational_index_option>::=

PAD_INDEX = { ON | AV }

FILLFACTOR = fillfactor

SORT_IN_TEMPDB = { ON | AV }

IGNORE_DUP_KEY = { ON | AV }

STATISTICS_NORECOMPUTE = { ON | OFF}

STATISTICS_INCREMENTAL = { ON | AV }

DROP_EXISTING = { ON | AV }

ONLINE = { ON | AV }

RESUMABLE = { ON | AV }

MAX_DURATION = tid [MINUTER] som används med RESUMABLE = ON (kräver ONLINE = ON)

ALLOW_ROW_LOCKS = { ON | AV }

ALLOW_PAGE_LOCKS = { ON | AV }

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | AV }

MAXDOP = max_degree_of_parallelism

DATA_COMPRESSION

XML_COMPRESSION

PÅ PARTITIONER ( { <partition_number_expression> | <intervall> } [ ,...n ] )

Anmärkningar

Klustrade index

Icke-grupperade index

Unika index

Partitionerade index

Filtrerade index

Obligatoriska SET-alternativ för filtrerade index

Rumsliga index

XML-index

Indexnyckelstorlek

Beräknade kolumner

Inkluderade kolumner i index

Ange indexalternativ

DROP_EXISTING-sats

ONLINE-alternativ

Återupptabara indexåtgärder

Resurser

Aktuella funktionsbegränsningar

WAIT_AT_LOW_PRIORITY med onlineindexåtgärder

Alternativ för rad- och sidlås

Sekventiella nycklar

Datakomprimering

XML-komprimering

Indexstatistik

Behörigheter

Begränsningar och begränsningar

Metadata

Versionsanteckningar

Exempel: Alla versioner. Använder AdventureWorks-databasen

A. Skapa ett enkelt icke-grupperat radlagringsindex

B. Skapa ett enkelt sammansatt rowstore-index som inte visas

C. Skapa ett index i en tabell i en annan databas

D. Lägga till en kolumn i ett index

Exempel: SQL Server, Azure SQL Database

E. Skapa ett unikt icke-grupperat index

F. Använd alternativet IGNORE_DUP_KEY

G. Använda DROP_EXISTING för att släppa och återskapa ett index

H. Skapa ett index i en vy

Jag. Skapa ett index med inkluderade kolumner (icke-nyckel)

MAX_DURATION = tid [MINUTER] som används med `RESUMABLE = ON` (kräver `ONLINE = ON`)