INDEX LÉTREHOZÁSA (Transact-SQL)

Vonatkozik a következőkre:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analitikai Platform System (PDW)SQL adatbázis a Microsoft Fabric-ben

Relációs indexet hoz létre egy táblán vagy nézeten. Sorcentrikus indexnek is nevezik, mert fürtözött vagy nem rendezett B-fa index. A táblázat adatai előtt létrehozhat egy sortárindexet. A lekérdezési teljesítmény javításához használjon sortárindexet, különösen akkor, ha a lekérdezések adott oszlopokból választanak, vagy egy adott sorrendben kell rendezni az értékeket.

Jegyzet

A dokumentáció általában a B-fa kifejezést használja az indexekre hivatkozva. A sorkataszterekben az adatbázismotor egy B+ fát implementál. Ez nem vonatkozik az oszlopcentrikus indexekre vagy a memóriaoptimalizált táblák indexére. További információ: SQL Server és Azure SQL index architektúrája és tervezési útmutatója.

Az Azure Synapse Analytics and Analytics Platform System (PDW) jelenleg nem támogatja az egyedi korlátozásokat. Bármilyen példa, amely egyedi korlátozásokra hivatkozik, csak az SQL Serverre, Azure SQL Database-re, SQL adatbázisra a Microsoft Fabric-ben és Azure SQL Managed Instance-ra alkalmazható.

Az indextervezési irányelvekről az SQL Server indextervezési útmutatójában olvashat.

példák:

Nemclustered index létrehozása táblán vagy nézetben
```
CREATE INDEX index1 ON schema1.table1 (column1);
```
Fürtözött index létrehozása egy táblán, és a tábla 3 részes neve
```
CREATE CLUSTERED INDEX index1 ON database1.schema1.table1 (column1);
```
Hozzon létre egy nemclustered indexet egyedi korlátozással, és adja meg a rendezési sorrendet
```
CREATE UNIQUE INDEX index1 ON schema1.table1 (column1 DESC, column2 ASC, column3 DESC);
```

kulcsforgatókönyv:

Az SQL Server 2016-tól (13.x) kezdve, Azure SQL Database-ben, SQL adatbázisban Microsoft Fabric-ben és Azure SQL Managed Instance-ban használhatsz nem klaszterezett indexet egy columnstore indexen az adattár lekérdezések teljesítményének javítására. További információ: Columnstore indexek – adattárház.

További indextípusokért lásd:

Transact-SQL szintaxis konvenciói

Szintaxis

Szintaxis az SQL Serverhez, az Azure SQL Database-hez, az SQL Database-hez a Fabricben, az 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>

Visszamenőlegesen kompatibilis relációs index

Fontos

A visszamenőlegesen kompatibilis relációs index szintaxisszerkezete az SQL Server egy későbbi verziójában törlődik. Ne használja ezt a szintaxisstruktúrát az új fejlesztési munkában, és tervezze meg a funkciót jelenleg használó alkalmazások módosítását. Használja inkább a <relational_index_option> megadott szintaxisstruktúrát.

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
}

Az Azure Synapse Analytics és a párhuzamos adattárház szintaxisa


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 } )
[;]

Érvek

EGYEDÜLÁLLÓ

Egyedi indexet hoz létre egy táblán vagy nézeten. Az egyedi index olyan, amelyben nincs két olyan sor, amelyben ugyanazzal az indexkulcs-értékkel rendelkezhet.

Az adatbázismotor nem teszi lehetővé egyedi index létrehozását olyan oszlopokon, amelyek már tartalmaznak duplikált értékeket, akár IGNORE_DUP_KEY be van állítva ON. Ha ezt megkísérli, az adatbázismotor hibaüzenetet jelenít meg. Az ismétlődő értékeket el kell távolítani, mielőtt egyedi indexet hozhat létre az oszlopon vagy oszlopokon.

A UNIQUE kényszereket NULL értékként kezeli. Ha egy oszlop null értékű, és UNIQUE az oszlopon kényszer van, legfeljebb egy sor NULL engedélyezett.

FÜRTÖZÖTT

Létrehoz egy indexet, amelyben az indexkulcs oszlopaihoz megadott rendezési sorrend határozza meg a lemez indexstruktúrájában lévő oldalsorrendet. A fürtözött index alsó vagy levélszintjén lévő sorok mindig tartalmazzák a táblázat összes oszlopát. Az index felső szintjein lévő lapok sorai csak a kulcsoszlopokat tartalmazzák.

Egy táblának csak egy klaszterezett indexe lehet. Ha egy táblán fürtözött index található, az a tábla összes adatát tartalmazza. A fürtözött index nélküli táblákat halomnak nevezzük.

Az egyedi fürtözött indexet tartalmazó nézeteket indexelt nézetnek nevezzük. Az indexelt nézetek csak egy fürtözött indexet tartalmazhatnak. Egy egyedi fürtözött index létrehozása egy nézetben fizikailag materializálja a nézetet. Egyedi fürtözött indexet kell létrehozni egy nézetben, mielőtt más indexek is definiálhatók ugyanazon a nézetben. További információ: Indexelt nézetek létrehozása.

Hozza létre a fürtözött indexet, mielőtt nem kizárólagos indexeket hoz létre. A táblák meglévő nemclustered indexei fürtözött index létrehozásakor újraépülnek, ami erőforrás-igényes művelet, ha a tábla nagy.

Ha CLUSTERED nincs megadva, létrejön egy nemclustered index.

Jegyzet

Mivel a fürtözött index a tábla összes adatát tartalmazza, fürtözött index létrehozása és a ON partition_scheme_name vagy ON filegroup_name záradék használata hatékonyan áthelyezi a táblát attól a fájlcsoporttól, amelyen a tábla létre lett hozva az új partíciós sémába vagy fájlcsoportba. Mielőtt táblákat vagy indexeket hoz létre adott fájlcsoportokon, ellenőrizze, hogy mely fájlcsoportok érhetők el, és hogy elegendő szabad hely áll-e rendelkezésre az index számára.

Bizonyos esetekben a fürtözött indexek létrehozása engedélyezheti a korábban letiltott indexeket. További információ: Indexek és korlátozások engedélyezése , indexek és megkötések letiltása.

NEMCLUSTERED

Létrehoz egy indexet, amelyben az indexkulcs oszlopaihoz megadott rendezési sorrend határozza meg a lemez indexstruktúrájában lévő oldalsorrendet. A fürtözött indextől eltérően a nem rendezett index lapjainak sorai csak az indexkulcs oszlopait tartalmazzák. Opcionálisan a nem kulcsos oszlopok egy részhalmaza is szerepelhet a INCLUDE záradék használatával.

Minden táblához legfeljebb 999 nem kizárólagos index tartozhat, függetlenül az indexek létrehozásának módjától: implicit módon és PRIMARY KEYUNIQUE korlátozásokkal, vagy explicit módon.CREATE INDEX

Indexelt nézetek esetén a nemclustered indexek csak olyan nézetben hozhatók létre, amely már definiált egyedi fürtözött indexet.

Ha nincs másként megadva, az alapértelmezett indextípus nem található meg.

index_name

Az index neve. Az indexneveknek egyedinek kell lenniük egy táblában vagy nézetben, de nem kell egyedinek lenniük az adatbázisban. Az indexneveknek az azonosítókszabályait kell követnie.

oszlop

Az az oszlop vagy oszlopok, amelyeken az index alapul. Adjon meg két vagy több oszlopnevet, hogy összetett indexet hozzon létre a megadott oszlopok összesített értékein. Sorolja fel az összetett indexbe belefoglalandó oszlopokat rendezési prioritási sorrendben, a zárójelek között table_or_view_nameután.

Legfeljebb 32 oszlop kombinálható egyetlen összetett indexkulcsba. Az összetett indexkulcs összes oszlopának ugyanabban a táblában vagy nézetben kell lennie. Az összevont indexértékek maximális megengedett mérete fürtözött index esetén 900 bájt, nemclustered index esetén 1700 bájt. A korlát 16 oszlop és 900 bájt az SQL Database és az SQL Server 2016 előtti verziók esetében (13.x).

A nagyméretű objektum (LOB) adattípusú oszlopok ntext, szöveg, varchar(max), nvarchar(max), varbinary(max), xmlvagy kép nem adhatók meg az index kulcsoszlopaként. Az indexelt nézetdefiníciók nem tartalmazhatnak ntext, szöveg vagy képoszlopokat , még akkor sem, ha az utasítás nem hivatkozik CREATE INDEX rájuk.

Ha a típus támogatja a bináris rendezést, akkor a CLR felhasználó által definiált típusoszlopokon létrehozhat indexeket. A felhasználó által definiált típusú oszlopból metódushívásként definiált számított oszlopokon is létrehozhat indexeket, amennyiben a metódusok determinisztikusként vannak megjelölve, és nem hajtanak végre adatelérési műveleteket. A CLR felhasználó által definiált típusú oszlopainak indexelésével kapcsolatos további információkért lásd a felhasználó által definiált CLR-típusokat.

[ ASC | LEÍRÁS ]

Meghatározza az adott indexoszlop növekvő vagy csökkenő rendezési irányát. Az alapértelmezett érték a ASC.

INCLUDE (oszlop [ ,... n ] )

Megadja a nem kulcs típusú oszlopokat, amelyeket hozzá kell adni egy nemclustered index levélszintéhez. A nemclustered index lehet egyedi vagy nem egyedi.

Az oszlopnevek nem ismételhetők meg a INCLUDE listában, és nem használhatók egyszerre kulcsként és nem kulcsoszlopként is. A nemclustered indexek mindig implicit módon tartalmazzák a fürtözött indexoszlopokat, ha a táblában fürtözött index van definiálva. További információ: Indexek létrehozása belefoglalt oszlopokkal.

Minden adattípus engedélyezett, kivéve szöveg, szövegés kép. Az SQL Server 2012-től (11.x) kezdve, az Azure SQL Database-ben, SQL adatbázisban a Microsoft Fabric-ben és Azure SQL Managed Instance-ban, ha bármelyik megadott nem kulcsos oszlop varchar(max), nvarchar(max) vagy varbinary(max) adattípus, az index összeállítható vagy újraépíthető az alábbi ONLINE opcióval.

A determinisztikus és pontos vagy pontatlan számított oszlopok is tartalmazhatnak oszlopokat. A képből, ntextből, szövegből, varchar(max), nvarchar(max), varbinary(max) és xml adattípusokból származtatott számított oszlopok mindaddig belefoglalhatók, amíg a számított oszlop adattípusa belefoglalt oszlopként engedélyezhető. A számított oszlopok indexeiről további információkért lásd a éshivatkozást.

Az XML-indexek létrehozásáról további információt CREATE XML INDEXcímű témakörben talál.

HOL <filter_predicate>

Szűrt indexet hoz létre az indexbe felvenni kívánt sorok megadásával. A szűrt indexnek nem kizárólagos indexnek kell lennie egy táblában. Szűrt statisztikákat hoz létre a szűrt index adatsoraihoz.

A szűrő predikátum egyszerű összehasonlító logikát használ, és nem hivatkozhat számított oszlopra, felhasználó által definiált adattípusú (UDT) oszlopra, térbeli adattípus-oszlopra vagy hierarchiaazonosító adattípus-oszlopra. Az összehasonlító operátorokat használó literálokkal NULL való összehasonlítás nem engedélyezett. Használja inkább a IS NULL és IS NOT NULL operátorokat.

Íme néhány példa a Production.BillOfMaterials táblára vonatkozó szűrő predikátumokra:

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

WHERE ComponentID IN (533, 324, 753)

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

A szűrt indexek nem vonatkoznak az XML-indexekre és a teljes szöveges indexekre. Indexek esetén UNIQUE csak a kijelölt soroknak kell egyedi indexértékekkel rendelkezniük. A szűrt indexek nem engedélyezik a IGNORE_DUP_KEY beállítást.

ON partition_scheme_name ( column_name )

Meghatározza azt a partíciós sémát, amely meghatározza azokat a fájlcsoportokat, amelyekre a particionált index partíciói le vannak képezve. A partíciósémának léteznie kell az adatbázisban a CREATE PARTITION SCHEME vagy ALTER PARTITION SCHEMEvégrehajtásával. column_name az index particionálási oszlopát adja meg. Ennek az oszlopnak meg kell egyeznie a partition_scheme_name használt partíciófüggvény argumentumának adattípusával, hosszával és pontosságával. column_name nem korlátozódik az indexdefiníció oszlopaira. Az alaptábla bármely oszlopa megadható, kivéve az egyedi index particionálását, column_name az egyedi kulcsként használtak közül kell választani. Ez a korlátozás lehetővé teszi, hogy az adatbázismotor csak egyetlen partíción belül ellenőrizze a kulcsértékek egyediségét.

Jegyzet

Nem egyedi fürtözött index particionálásakor az adatbázismotor alapértelmezés szerint hozzáadja a particionálási oszlopot a fürtözött indexkulcsok listájához, ha még nincs megadva. Nem egyedi, nemclustered index particionálásakor az adatbázismotor hozzáadja a particionálási oszlopot az index nem kulcs (belefoglalt) oszlopaként, ha még nincs megadva.

Ha partition_scheme_name vagy fájlcsoport nincs megadva, és a tábla particionálásra kerül, az index ugyanabba a partíciós sémába kerül, ugyanazzal a particionálási oszloptal, mint az alapul szolgáló tábla.

Jegyzet

XML-indexek particionálási sémája nem adható meg. Ha az alaptábla particionálása történik, az XML-index ugyanazt a partíciós sémát használja, mint a táblát.

További információ az indexek, particionált táblák és indexek particionálásáról.

A filegroup_name

Létrehozza a megadott indexet a megadott fájlcsoporton. Ha nincs megadva hely, és a tábla vagy nézet nincs particionálva, az index ugyanazt a fájlcsoportot használja, mint az alapul szolgáló tábla vagy nézet. A fájlcsoportnak már léteznie kell.

ON [alapértelmezett]

A megadott indexet ugyanazon a fájlcsoporton vagy partíciós sémán hozza létre, mint a tábla vagy a nézet.

A kifejezés defaultebben a kontextusban nem kulcsszó. Ez a tábla vagy nézet fájlcsoportjának vagy particionált sémájának azonosítója, és el kell tagoltnak lennie, mint a fájlban vagy ON "default"a nézetbenON [default]. Ha "default" meg van adva, a QUOTED_IDENTIFIER beállításnak az aktuális munkamenethez kell lennie ON . Ez az alapértelmezett beállítás. További információ: SET QUOTED_IDENTIFIER.

Jegyzet

Az adatbázis alapértelmezett fájlcsoportját CREATE INDEX"default"[default] ne jelezze a környezetében. Jelzik az alaptábla vagy nézet által használt fájlcsoportot vagy partíciós sémát. Ez eltér az alapértelmezett adatbázisfájlcsoport helyétől CREATE TABLEés "default"[default] helyétől.

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

A TÁBLA FILESTREAM-adatainak elhelyezését adja meg fürtözött index létrehozásakor. A FILESTREAM_ON záradék lehetővé teszi a FILESTREAM-adatok áthelyezését egy másik FILESTREAM-fájlcsoportba vagy partíciós sémába.

A filestream_filegroup_name egy FILESTREAM-fájlcsoport neve. A fájlcsoportnak egy fájllal kell rendelkeznie a fájlcsoporthoz egy CREATE DATABASE vagy ALTER DATABASE utasítás használatával; ellenkező esetben hiba jelenik meg.

Ha a tábla particionálásra kerül, a FILESTREAM_ON záradékot fel kell venni, és meg kell adnia a FILESTREAM-fájlcsoportok partíciós sémáját, amely ugyanazt a partíciófüggvényt és partícióoszlopokat használja, mint a tábla partíciós sémája. Ellenkező esetben hiba merül fel.

Ha a tábla nincs particionálva, a FILESTREAM oszlop nem particionálható. A tábla FILESTREAM-adatait egyetlen fájlcsoportban kell tárolni, amely a FILESTREAM_ON záradékban van megadva.

FILESTREAM_ON NULL CREATE INDEX utasításban is megadható, ha fürtözött indexet hoz létre, és a tábla nem tartalmaz FILESTREAM oszlopot.

További információ: FILESTREAM (SQL Server).

<objektum>::=

Az indexelendő teljes vagy nem minősített objektum.

database_name

Az adatbázis neve.

schema_name

Annak a sémának a neve, amelyhez a tábla vagy nézet tartozik.

table_or_view_name

Az indexelendő tábla vagy nézet neve.

Ha indexet szeretne létrehozni egy nézetben, a nézetet a következővel SCHEMABINDINGkell definiálni: . A nem kizárólagos indexek létrehozása előtt egyedi fürtözött indexet kell létrehozni egy nézetben. Az indexelt nézetekről további információt a Megjegyzések című témakörben talál.

Az SQL Server 2016 -tól kezdve (13.x) az objektum lehet egy fürtözött oszlopcentrikus indexkel tárolt tábla.

Az Azure SQL Database támogatja a háromrészes névformátumot <database_name>.<schema_name>.<object_name>, ha <database_name> az aktuális adatbázisnév, vagy <database_name>tempdb, és <object_name># vagy ##kezdődik. Ha a séma neve dbo, <schema_name> kihagyható.

< >relational_index_option::=

Megadja az index létrehozásakor használni kívánt beállításokat.

PAD_INDEX = { ON | KI }

Az indexek kitöltését adja meg. Az alapértelmezett érték a OFF.

RA

A kitöltési tényező által megadott szabad terület százalékos aránya az index közbenső szintű lapjaira lesz alkalmazva. Ha FILLFACTOR nincs megadva egyszerre, PAD_INDEXONértékre van állítva, a rendszer a sys.indexes kitöltési tényező értékét használja.
KI

A köztes szintű lapok kapacitása megközelíti a kapacitást, és elegendő helyet hagy az index által megengedett legnagyobb méretű sornak, figyelembe véve a köztes lapok kulcskészletét. Ez akkor is előfordul, ha PAD_INDEXON van beállítva, de a kitöltési tényező nincs megadva.

A PAD_INDEX beállítás csak akkor hasznos, ha FILLFACTOR meg van adva, mert PAD_INDEX a megadott FILLFACTORszázalékot használja. Ha a megadott FILLFACTOR százalék nem elég nagy egy sor engedélyezéséhez, az adatbázismotor belsőleg felülbírálja a százalékos értéket a minimális érték engedélyezéséhez. A köztes indexlapon lévő sorok száma soha nem kisebb kettőnél, függetlenül attól, hogy a sorok értéke FILLFACTORmennyire alacsony.

A visszamenőlegesen kompatibilis szintaxisban a WITH PAD_INDEX egyenértékű a WITH PAD_INDEX = ON.

FILLFACTOR = fillfactor

Százalékos értéket ad meg, amely azt jelzi, hogy az adatbázismotornak mennyire kell az egyes indexlapok levélszintjének szintjét létrehoznia az index létrehozása vagy újraépítése során. A kitöltési értéknek 1 és 100 közötti egész számnak kell lennie. A 0 és a 100 kitöltési tényező értéke minden tekintetben megegyezik. Ha fillfactor 100, az adatbázismotor olyan indexeket hoz létre, amelyek levéloldalait kapacitásba töltik.

A FILLFACTOR beállítás csak az index létrehozásakor vagy újraépítésekor érvényes. Az adatbázismotor nem tartja dinamikusan a lapokban megadott üres terület százalékos arányát.

A kitöltési tényező beállításának megtekintéséhez használja az fill_factor oszlopot a sys.indexes katalógusnézetben.

Fontos

Egy 100-nál kisebb FILLFACTOR rendelkező index létrehozása növeli az adatok által elfoglalt tárterületet, mivel az adatbázismotor az index létrehozásakor vagy újraépítésekor a kitöltési tényezőnek megfelelően terjeszti újra az adatokat.

További információt az index kitöltési tényezőinek megadása című témakörben talál.

SORT_IN_TEMPDB = { ON | KI }

Megadja, hogy az ideiglenes rendezési eredményeket a tempdbtárolja-e. Az alapértelmezett érték OFF, kivéve az Azure SQL Database rugalmas skálázását. A rugalmas skálázásban lévő összes index-összeállítási művelet esetében SORT_IN_TEMPDB mindig ON, hacsak nem használ újrahasználható index buildet. Az újra felhasználható index buildek esetében SORT_IN_TEMPDB mindig OFF.

RA

Az index létrehozásához használt köztes rendezési eredményeket a rendszer tempdbtárolja. Ez csökkentheti az index létrehozásához szükséges időt. Ez azonban növeli az index buildelése során használt lemezterületet.
KI

A köztes rendezési eredmények ugyanabban az adatbázisban vannak tárolva, mint az index.

A felhasználói adatbázisban az index tempdb létrehozásához szükséges hely mellett körülbelül annyi további területtel kell rendelkeznie a köztes rendezési eredmények tárolásához. További információt az indexek SORT_IN_TEMPDB beállításában talál.

A visszamenőlegesen kompatibilis szintaxisban a WITH SORT_IN_TEMPDB egyenértékű a WITH SORT_IN_TEMPDB = ON.

IGNORE_DUP_KEY = { ON | KI }

Megadja a hibaválaszt, amikor egy beszúrási művelet ismétlődő kulcsértékeket próbál beszúrni egy egyedi indexbe. A IGNORE_DUP_KEY beállítás csak az index létrehozása vagy újraépítése után történő beszúrási műveletekre vonatkozik. A beállításnak nincs hatása CREATE INDEX, ALTER INDEXvagy UPDATEvégrehajtásakor. Az alapértelmezett érték a OFF.

RA

Figyelmeztető üzenet jelenik meg, ha ismétlődő kulcsértékeket szúr be egy egyedi indexbe. Csak az egyediségi korlátozást megsértő sorok nincsenek beszúrva.
KI

Hibaüzenet jelenik meg, ha ismétlődő kulcsértékeket szúr be egy egyedi indexbe. A teljes INSERT utasítás vissza lesz állítva.

IGNORE_DUP_KEY nem állítható be ON nézeten létrehozott indexekhez, nem egyedi indexekhez, XML-indexekhez, térbeli indexekhez és szűrt indexekhez.

Az index IGNORE_DUP_KEY beállításának megtekintéséhez használja a ignore_dup_key oszlopot a sys.indexes katalógusnézetben.

A visszamenőlegesen kompatibilis szintaxisban a WITH IGNORE_DUP_KEY egyenértékű a WITH IGNORE_DUP_KEY = ON.

STATISTICS_NORECOMPUTE = { ON | KI}

Megadja, hogy a statisztikák újrafordításra kerülnek-e. Az alapértelmezett érték a OFF.

RA

A elavult statisztikák nem lesznek automatikusan újrafordítve.
KI

Az automatikus statisztikák frissítése engedélyezve van.

Az automatikus statisztikák frissítésének visszaállításához állítsa a STATISTICS_NORECOMPUTE KI értékre, vagy hajtsa végre a UPDATE STATISTICS a NORECOMPUTE záradék nélkül.

Figyelmeztetés

Ha STATISTICS_NORECOMPUTE = ONbeállításával letiltja a statisztikák automatikus újraszámítását, megakadályozhatja, hogy a lekérdezésoptimalizáló optimális végrehajtási terveket válasszon a táblát érintő lekérdezésekhez.

A STATISTICS_NORECOMPUTEON beállítása nem akadályozza meg az index-újraépítési művelet során előforduló indexstatisztikák frissítését.

A visszamenőlegesen kompatibilis szintaxisban a WITH STATISTICS_NORECOMPUTE egyenértékű a WITH STATISTICS_NORECOMPUTE = ON.

STATISTICS_INCREMENTAL = { ON | KI }

Érvényes: SQL Server 2014 (12.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Amikor ONa létrehozott statisztikák partíciónkénti statisztikák. Amikor OFFa statisztikai fa el lesz ejtve, és az SQL Server újra kiszámítja a statisztikákat. Az alapértelmezett érték a OFF.

Ha a partíciónkénti statisztikák nem támogatottak, a beállítás figyelmen kívül lesz hagyva, és figyelmeztetés jön létre. A növekményes statisztikák nem támogatottak a következő esetekben:

Olyan indexekkel létrehozott statisztikák, amelyek nincsenek partícióhoz igazítva az alaptáblához.
Az Always On olvasható másodlagos adatbázisokon létrehozott statisztikák.
Írásvédett adatbázisokon létrehozott statisztikák.
Szűrt indexeken létrehozott statisztikák.
Nézeteken létrehozott statisztikák.
Belső táblákon létrehozott statisztikák.
Térbeli indexekkel vagy XML-indexekkel létrehozott statisztikák.

DROP_EXISTING = { ON | KI }

Lehetőség van a meglévő fürtözött vagy nemclustered index elvetésére és újraépítésére módosított oszlopspecifikációkkal, és megtarthatja az index nevét. Az alapértelmezett érték a OFF.

RA

A meglévő index elvetésére és újraépítésére szolgál, amelynek ugyanazzal a névvel kell rendelkeznie, mint a index_nameparaméternek.
KI

Azt határozza meg, hogy a meglévő index ne vesse el és ne legyen újraépítve. Az SQL Server hibát jelenít meg, ha a megadott indexnév már létezik.

A DROP_EXISTINGa következőt módosíthatja:

Nemclustered rowstore index egy fürtözött soráruház-indexhez.

A DROP_EXISTINGnem módosítható:

Fürtözött soráruház-index nemclustered rowstore indexre.
Fürtözött oszlopcentrikus index bármilyen típusú sortárindexhez.

A visszamenőlegesen kompatibilis szintaxisban a WITH DROP_EXISTING egyenértékű a WITH DROP_EXISTING = ON.

ONLINE = { ON | KI }

Megadja, hogy a mögöttes táblák és a kapcsolódó indexek elérhetők-e a lekérdezésekhez és az adatok módosításához az indexművelet során. Az alapértelmezett érték a OFF.

Fontos

Az online indexelési műveletek nem érhetők el a Microsoft SQL Server minden kiadásában. Az SQL Server kiadásai által támogatott funkciók listáját az SQL Server 2022Kiadásai és támogatott funkciói című témakörben találja.

RA

A hosszú távú táblazárolások nem az indexművelet időtartamára vannak tárolva. Az indexművelet fő fázisában csak a szándék megosztott (IS) zárolása van tárolva a forrástáblában. Ez lehetővé teszi a mögöttes tábla és indexek lekérdezéseinek vagy frissítéseinek folytatását. A művelet kezdetén egy megosztott (S) zárolás van tárolva a forrásobjektumon egy rövid ideig. A művelet végén, rövid ideig egy megosztott (S) zárolást szerez be az objektumon, ha nemclustered index jön létre. A rendszer sémamódosítási (Sch-M) zárolást szerez be a fürtözött indexek létrehozásakor vagy online elvetésekor, valamint egy fürtözött vagy nemclustered index újraépítésekor. ONLINE nem állítható be ON, ha indexet hoz létre egy helyi ideiglenes táblában.

Jegyzet

A WAIT_AT_LOW_PRIORITY beállítással csökkentheti vagy elkerülheti a blokkolást az online indexműveletek során. További információ: WAIT_AT_LOW_PRIORITY online indexműveletekkel.
KI

A rendszer táblazárolásokat alkalmaz az indexművelet időtartamára. Egy offline indexművelet, amely fürtözött, térbeli vagy XML-indexet hoz létre, újraépít vagy elvet, vagy újjáépít vagy elvet egy nemclustered indexet, sémamódosítási (Sch-M) zárolást szerez be a táblán. Ez megakadályozza, hogy a művelet időtartama alatt minden felhasználó hozzáférjen a mögöttes táblához. Egy offline indexművelet, amely nem kizárólagos indexet hoz létre, először egy megosztott (S) zárolást szerez be a táblán. Ez megakadályozza az alapul szolgáló tábladefiníció módosítását, de lehetővé teszi a tábla adatainak olvasását és módosítását, miközben az index összeállítása folyamatban van.

További információ: Indexműveletek online végrehajtása és online indexelési műveletekre vonatkozó irányelvek.

Az indexek, beleértve a globális ideiglenes táblák indexeit is, az alábbi esetek kivételével hozhatók létre online:

XML-index
Indexelés helyi ideiglenes táblán
Kezdeti egyedi fürtözött index egy nézetben
Letiltott fürtözött indexek
Fürtözött oszlopcentrikus indexek az SQL Server 2017 -ben (14.x)) és a régebbi verziókban
Nemclustered columnstore indexek az SQL Server 2016 (13.x)) és a régebbi verziókban
Fürtözött index, ha az alapul szolgáló tábla LOB adattípusokat (kép, ntext, szöveg) és térbeli adattípusokat tartalmaz
varchar(max) és varbinary(max) oszlop nem lehet indexkulcs része. SQL Serverben (az SQL Server 2012-től (11.x)), az Azure SQL Database-ben, SQL adatbázisban a Microsoft Fabric-ben, valamint Azure SQL Managed Instance-ban, amikor egy tábla varchar(max) vagy varbinary(max) oszlopokat tartalmaz, egy klaszterelt index, amely más oszlopokat tartalmaz, létrehozható vagy újraépíthető az opcióval ONLINE .
Nemclustered indexek fürtözött oszlopcentrikus indexet tartalmazó táblán

További információ: Az online indexműveletek működése.

RESUMABLE = { ON | KI }

Alkalmazható: SQL Server 2019 (15.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Megadja, hogy egy online indexművelet folytatható-e. További információkért lásd: Újraműveleti indexműveletek és Újraértékelhető index szempontjai.

RA

Az indexművelet folytatható.
KI

Az indexművelet nem folytatható újra.

MAX_DURATION = idő [PERC] `RESUMABLE = ON` (`ONLINE = ON`szükséges)

Alkalmazható: SQL Server 2019 (15.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Azt határozza meg, hogy a rendszer mennyi ideig hajt végre újraumatható indexelési műveletet a szüneteltetés előtt.

ALLOW_ROW_LOCKS = { ON | KI }

Megadja, hogy engedélyezettek-e a sorzárolások. Az alapértelmezett érték a ON.

RA

Az index elérésekor sorzárolások engedélyezettek. Az adatbázismotor határozza meg a sorzárolások használatát.
KI

A sorzárak nem használhatók.

ALLOW_PAGE_LOCKS = { ON | KI }

Megadja, hogy engedélyezettek-e az oldalzárolások. Az alapértelmezett érték a ON.

RA

Az index elérésekor az oldalzárolások engedélyezettek. Az adatbázismotor határozza meg az oldalzárolások használatát.
KI

Az oldalzárak nem használhatók.

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | KI }

Alkalmazható: SQL Server 2019 (15.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Itt adhatja meg, hogy optimalizálja-e az utolsó oldal beszúrásának elkerülését. Az alapértelmezett érték a OFF. További információért tekintse meg a Szekvenciális kulcsok szakaszt.

MAXDOP = max_degree_of_parallelism

Felülbírálja az indexművelet maximális párhuzamossági fokát. További információ: A kiszolgáló konfigurációs beállításainak maximális fokának konfigurálása. A MAXDOP használatával korlátozhatja a párhuzamosság mértékét és az eredményként kapott erőforrás-felhasználást az index buildelési műveletéhez.

max_degree_of_parallelism lehet:

1

Letiltja a párhuzamos tervgenerálást.
>1

A párhuzamos indexműveletekben használt párhuzamosság maximális fokát a megadott számra vagy annál kisebbre korlátozza az aktuális rendszerterhelés alapján.
0 (alapértelmezett)

A kiszolgáló, adatbázis vagy számítási feladatcsoport szintjén megadott párhuzamosság mértékét használja, kivéve, ha az aktuális rendszerterhelés alapján csökken.

További információ: Párhuzamos indexelési műveletek konfigurálása.

Jegyzet

A párhuzamos indexműveletek nem érhetők el a Microsoft SQL Server minden kiadásában. Az SQL Server kiadásai által támogatott funkciók listáját az SQL Server 2022Kiadásai és támogatott funkciói című témakörben találja.

DATA_COMPRESSION

Megadja a megadott index, partíciószám vagy partíciótartomány adattömörítési beállítását. A lehetőségek a következők:

Egyik sem

Az index vagy a megadott partíciók nincsenek tömörítve. Ez nem vonatkozik az oszlopcentrikus indexekre.
SOR

Az index vagy a megadott partíciók sortömörítéssel vannak tömörítve. Ez nem vonatkozik az oszlopcentrikus indexekre.
OLDAL

Az index vagy a megadott partíciók laptömörítéssel vannak tömörítve. Ez nem vonatkozik az oszlopcentrikus indexekre.
COLUMNSTORE

Érvényes: SQL Server 2014 (12.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Csak oszlopcentrikus indexekre vonatkozik, beleértve a nemclustered columnstore és a fürtözött oszlopcentrikus indexeket is.
COLUMNSTORE_ARCHIVE

Érvényes: SQL Server 2014 (12.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Csak oszlopcentrikus indexekre vonatkozik, beleértve a nemclustered columnstore és a fürtözött oszlopcentrikus indexeket is. COLUMNSTORE_ARCHIVE a megadott partíciót kisebb méretűre tömöríti. Ez felhasználható archiválásra vagy más olyan helyzetekre, amelyek kisebb tárterületet igényelnek, és több időt engedhetnek meg a tárolásra és a lekérésre.

További információ a tömörítésről: Adattömörítési.

XML_COMPRESSION

Érvényes: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Megadja a megadott index XML-tömörítési beállítását, amely egy vagy több xml adattípus-oszlopot tartalmaz. A lehetőségek a következők:

RA

Az index vagy a megadott partíciók XML-tömörítéssel vannak tömörítve.
KI

Az index vagy a megadott partíciók nem xml-tömörítéssel vannak tömörítve.

PARTÍCIÓKON ( { <partition_number_expression> | <tartomány> } [ ,...n ] )

Meghatározza azokat a partíciókat, amelyekre a DATA_COMPRESSION vagy XML_COMPRESSION beállítások vonatkoznak. Ha az index nincs particionálva, a ON PARTITIONS argumentum hibát okoz. Ha a ON PARTITIONS záradék nincs megadva, a DATA_COMPRESSION vagy XML_COMPRESSION beállítás a particionált index összes partíciójára vonatkozik.

<partition_number_expression> a következő módokon adhatók meg:

Adja meg egy partíció számát, például: ON PARTITIONS (2).
Adja meg a partíciószámokat több, vesszővel elválasztott partícióhoz, például: ON PARTITIONS (1, 5).
Adja meg a tartományokat és az egyes partíciókat, például: ON PARTITIONS (2, 4, 6 TO 8).

<range> a kulcsszóval TOelválasztott partíciószámokként adható meg, például: ON PARTITIONS (6 TO 8).

Ha különböző típusú adattömörítést szeretne beállítani a különböző partíciókhoz, adja meg többször a DATA_COMPRESSION beállítást, például:

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)
);

A XML_COMPRESSION lehetőséget többször is megadhatja, például:

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)
);

Megjegyzések

Az utasítás lekérdezési tervének CREATE INDEX létrehozásakor a lekérdezésoptimalizáló dönthet úgy, hogy táblázatvizsgálat helyett egy másik indexet keres. Előfordulhat, hogy a rendezési művelet bizonyos helyzetekben megszűnik. Többprocesszoros számítógépeken CREATE INDEX a párhuzamosság használható az index létrehozásához kapcsolódó vizsgálati és rendezési műveletekhez, ugyanúgy, mint a többi lekérdezés. További információ: Párhuzamos indexelési műveletek konfigurálása.

A CREATE INDEX művelet minimálisan naplózható, ha az adatbázis-helyreállítási modell tömeges naplózásra vagy egyszerűre van állítva.

Az indexek ideiglenes táblán hozhatók létre. Amikor a tábla el van dobva, vagy kimegy a hatókörből, a rendszer elveti az indexeket.

A fürtözött indexek egy táblaváltozóra épülnek, amikor elsődleges kulcskényszert adnak hozzá. Hasonlóképpen, a nemclustered indexek egy táblaváltozóra épülnek, amikor egyedi korlátozást adnak hozzá. Amikor a táblaváltozó kiesik a hatókörből, a rendszer elveti az indexeket.

Az indexek támogatják a kiterjesztett tulajdonságokat.

CREATE INDEX a Microsoft Fabric nem támogatja.

Fürtözött indexek

Ha fürtözött indexet hoz létre egy táblán (halom), vagy elveti és újra létrehozza a meglévő fürtözött indexet, további munkaterületnek kell rendelkezésre állnia az adatbázisban az adatok rendezéséhez, valamint az eredeti tábla vagy a meglévő fürtözött indexadatok ideiglenes másolatának elhelyezéséhez. A fürtözött indexekről további információt a fürtözött indexek létrehozása , valamint az SQL Server indexarchitektúrája és tervezési útmutatója tartalmaz.

Nemclustered indexek

Az SQL Server 2016-tól (13.x) kezdve, Azure SQL Database-ben, SQL adatbázisban Microsoft Fabricben és Azure SQL Managed Instance-ban létrehozhatsz egy nem klaszterelt indexet egy táblázaton, amely klaszterelt columnstore indexként tárolt. Ha először létrehoz egy nemclustered indexet egy halomként vagy fürtözött indexként tárolt táblán, az index megmarad, ha később fürtözött oszlopcentrikus indexké konvertálja a táblát. A fürtözött oszlopcentrikus index újraépítésekor nem szükséges elvetni a nemclustered indexet.

A FILESTREAM_ON beállítás nem érvényes, ha fürtözött oszlopcentrikus indexként tárolt táblán nemclustered indexet hoz létre.

Egyedi indexek

Ha létezik egyedi index, az adatbázismotor minden adat hozzáadásakor vagy módosításakor ellenőrzi az ismétlődő értékeket. A rendszer visszaállítja az ismétlődő kulcsértékeket generáló műveleteket, és az adatbázismotor hibaüzenetet ad vissza. Ez akkor is igaz, ha az adat-összeadási vagy módosítási művelet sok sort módosít, de csak egy ismétlődést okoz. Ha sorokat próbál beszúrni, ha egy egyedi index IGNORE_DUP_KEY van beállítva ON, a rendszer figyelmen kívül hagyja az egyedi indexet megsértő sorokat.

Particionált indexek

A particionált indexek a particionált táblákhoz hasonlóan jönnek létre és tarthatók karban, de a szokásos indexekhez hasonlóan külön adatbázis-objektumként kezelik őket. Egy nem particionált táblán particionált index is lehet, és particionált táblán nem particionált index is lehet.

Ha egy particionált táblán hoz létre indexet, és nem adja meg azt a fájlcsoportot, amelyre az indexet helyezni szeretné, az index particionálása ugyanúgy történik, mint a mögöttes tábla. Ennek az az oka, hogy az indexek alapértelmezés szerint ugyanazon a fájlcsoporton vannak elhelyezve, mint a mögöttes táblák, és egy particionált tábla esetében ugyanabban a partíciós sémában, amely ugyanazokat a particionálási oszlopokat használja. Ha az index ugyanazt a partíciós sémát és particionálási oszlopot használja, mint a tábla, az index igazodik a táblához.

Figyelmeztetés

Az 1000-nél több partíciót tartalmazó táblákon nem számított indexek létrehozása és újraépítése lehetséges, de nem támogatott. Ez a művelet csökkentett teljesítményt vagy túlzott memóriahasználatot okozhat ezen műveletek során. Azt javasoljuk, hogy csak akkor használjon igazított indexeket, ha a partíciók száma meghaladja az 1000-et.

Nem egyedi, fürtözött index particionálásakor az adatbázismotor alapértelmezés szerint hozzáadja a particionálási oszlopokat a fürtözött indexkulcsok listájához, ha még nincs megadva.

Az indexelt nézetek ugyanúgy hozhatók létre particionált táblákon, mint a táblák indexei. A particionált indexekről további információt a particionált táblák és indexek , valamint az SQL Server indexarchitektúrája és tervezési útmutatója tartalmaz.

Index létrehozásakor vagy újraépítésekor a lekérdezés optimalizálja az index frissítési statisztikáit. Particionált indexek esetén a lekérdezésoptimalizáló az alapértelmezett mintavételezési algoritmust használja ahelyett, hogy a tábla összes sorát beolvasta egy nem particionált indexhez. A particionált indexekre vonatkozó statisztikák a tábla összes sorának vizsgálatával történő lekéréséhez használja CREATE STATISTICS vagy UPDATE STATISTICS a FULLSCAN záradékkal.

Szűrt indexek

A szűrt index egy optimalizált, nemclustered index, amely olyan lekérdezésekhez használható, amelyek a tábla sorainak kis százalékát választják ki. Szűrő predikátumot használ a tábla adatainak egy részének indexeléséhez. A jól megtervezett szűrt index javíthatja a lekérdezési teljesítményt, csökkentheti a tárolási költségeket és csökkentheti a karbantartási költségeket.

A szűrt indexekhez szükséges SET-beállítások

A SETKötelező érték oszlop beállításaira az alábbi feltételek bármelyike esetén szükség van:

Szűrt indexet hoz létre.
A INSERT, UPDATE, DELETEvagy MERGE utasítás módosítja a szűrt index adatait.

A szűrt indexet a lekérdezésoptimalizáló használja a lekérdezésterv létrehozásához.

`SET` lehetőség	Kötelező érték	Alapértelmezett kiszolgálóérték	Alapértelmezett OLE DB- és ODBC-érték	Alapértelmezett DB-Library érték
`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`

¹ Az ANSI_WARNINGSON implicit ARITHABORT beállítás értéke ON az adatbázis kompatibilitási szintjének 90-es vagy magasabb értékére van állítva. Ha az adatbázis kompatibilitási szintje 80-ra vagy korábbira van állítva, a ARITHABORT beállítást explicit módon be kell állítani ON.

Ha a SET beállítások helytelenek, a következő feltételek léphetnek fel:

A szűrt index létrehozása sikertelen.
Az adatbázismotor hibát generál, és visszaállítja az INSERTindex adatait módosító , UPDATE, DELETEvagy MERGE utasítást.
A lekérdezésoptimalizáló nem veszi figyelembe a végrehajtási tervben szereplő indexet Transact-SQL utasítások esetében.

A szűrt indexekről további információt a Szűrt indexek létrehozása , valamint az SQL Server indexarchitektúrája és tervezési útmutatója tartalmaz.

Térbeli indexek

A térbeli indexekről további információt a CREATE SPATIAL INDEX and Spatial indexes áttekintésben talál.

XML-indexek

Az XML-indexekről további információt CREATE XML INDEX és XML-indexek (SQL Server).

Indexkulcs mérete

Az indexkulcsok maximális mérete fürtözött index esetén 900 bájt, nemclustered index esetén pedig 1700 bájt. (Az SQL Database és az SQL Server 2016 (13.x) előtt a korlát mindig 900 bájt volt.) A bájtkorlátot meghaladó varchar-oszlopok indexei akkor hozhatók létre, ha az oszlopokban lévő meglévő adatok nem lépik túl a korlátot az index létrehozásakor; azonban a későbbi beszúrási vagy frissítési műveletek az oszlopokon, amelyek miatt a teljes méret nagyobb a korlátnál. A fürtözött index indexkulcsa nem tartalmazhat varchar oszlopokat, amelyek a ROW_OVERFLOW_DATA foglalási egységben már létező adatokkal rendelkeznek. Ha egy varchar oszlopban fürtözött index jön létre, és a meglévő adatok a IN_ROW_DATA foglalási egységben találhatók, a soron kívüli adatokat letöltő oszlop későbbi beszúrási vagy frissítési műveletei meghiúsulnak.

A nemclustered indexek tartalmazhatnak nem kulcs (belefoglalt) oszlopokat az index levélszintjében. Ezeket az oszlopokat az adatbázismotor nem veszi figyelembe az indexkulcs méretének kiszámításakor. További információ: Indexek létrehozása a mellékelt oszlopokkal , valamint az SQL Server indexarchitektúrája és tervezési útmutatója.

Jegyzet

Ha a táblák particionálásakor a particionálási kulcsoszlopok még nem találhatók meg egy nem egyedi fürtözött indexben, az adatbázismotor hozzáadja őket az indexhez. Az indexelt oszlopok összesített mérete (nem számítva a belefoglalt oszlopokat), valamint a hozzáadott particionálási oszlopok száma nem haladhatja meg az 1800 bájtot egy nem egyedi fürtözött indexben.

Számított oszlopok

Az indexek számítási oszlopokon hozhatók létre. Emellett a számított oszlopok is rendelkezhetnek a tulajdonságdal PERSISTED. Ez azt jelenti, hogy az adatbázismotor tárolja a számított értékeket a táblában, és frissíti őket, amikor a számított oszloptól függő egyéb oszlopok frissülnek. Az adatbázismotor akkor használja ezeket a megőrzött értékeket, amikor indexet hoz létre az oszlopon, és amikor az indexre hivatkozik egy lekérdezés.

A számított oszlop indexeléséhez a számított oszlopnak determinisztikusnak és pontosnak kell lennie. A tulajdonság használata PERSISTED azonban kiterjeszti az indexelhető számított oszlopok típusát a következőkre:

Számított oszlopok Transact-SQL és CLR-függvények, valamint a felhasználó által determinisztikusként megjelölt CLR-típusmódszerek alapján.
Az adatbázismotor által definiált, de pontatlan kifejezéseken alapuló számított oszlopok.

A megőrzött számított oszlopokhoz az alábbi SET beállításokat kell megadni, ahogyan az előző szakaszban a szűrt indexekhez szükséges SET beállításokat tartalmaz.

A UNIQUE vagy PRIMARY KEY kényszer tartalmazhat számított oszlopot, ha megfelel az indexelés minden feltételének. A kiszámított oszlopnak determinisztikusnak, pontosnak vagy determinisztikusnak kell lennie, és meg kell őriznie. További információ a determinizmusról: Determinisztikus és Nemdeterminista függvények.

Számított oszlopok kép, ntext, szöveg, varchar(max), nvarchar(max), varbinary(max)és xml adattípusok indexelhetők kulcsként vagy nem kulcsoszlopként, feltéve, hogy a számított oszlop adattípusa indexkulcs-oszlopként vagy nem kulcsoszlopként engedélyezhető. Nem hozható létre például elsődleges XML-index egy számított XML- oszlopon. Ha az indexkulcs mérete meghaladja a 900 bájtot, figyelmeztető üzenet jelenik meg.

Ha egy indexet egy számított oszlopon hoz létre, az egy korábban használt beszúrási vagy frissítési művelet meghiúsulását okozhatja. Ilyen hiba akkor fordulhat elő, ha a számított oszlop aritmetikai hibát eredményez.

Például a következő táblázatban, bár a kiszámított oszlop c kifejezése számtani hibát eredményez a sor beszúrásakor, az INSERT utasítás működik.

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

Ha azonban indexet hoz létre a számított oszlopban c, ugyanaz INSERT az utasítás meghiúsul.

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);

A számított oszlopok indexeiről további információkért lásd a éshivatkozást.

Belefoglalt oszlopok az indexekbe

A nem kulcsos oszlopok, az úgynevezett belefoglalt oszlopok hozzáadhatók a nemclustered index levélszintéhez a lekérdezés lefedésével a lekérdezés teljesítményének javítása érdekében. Vagyis a lekérdezésben hivatkozott összes oszlop kulcsként vagy nem kulcsoszlopként szerepel az indexben. Ez lehetővé teszi, hogy a lekérdezésoptimalizáló lekérte az összes szükséges információt egy nem konklúziós indexvizsgálatból vagy keresésből; a tábla vagy a fürtözött index adatai nem érhetők el. További információ: Indexek létrehozása a mellékelt oszlopokkal , valamint az SQL Server indexarchitektúrája és tervezési útmutatója.

Indexbeállítások megadása

Az SQL Server 2005 (9.x) új indexbeállításokat vezetett be, és módosította a beállítások megadásának módját is. A visszamenőlegesen kompatibilis szintaxis WITH option_name a következőnek felel meg WITH (option_name = ON): . Az indexbeállítások megadásakor a következő szabályok érvényesek:

Az új indexbeállítások csak a WITH (<option_name> = <ON | OFF>)használatával adhatók meg.
A beállítások nem adhatók meg úgy, hogy a visszamenőlegesen kompatibilis és az új szintaxist ugyanabban az utasításban használják. A WITH (DROP_EXISTING, ONLINE = ON) megadása például az utasítás sikertelenségéhez vezet.
XML-index létrehozásakor a beállításokat WITH (<option_name> = <ON | OFF>)használatával kell megadni.

DROP_EXISTING záradék

A DROP_EXISTING záradék használatával újraépítheti az indexet, oszlopokat vehet fel vagy helyezhet el, módosíthatja a beállításokat, módosíthatja az oszlop rendezési sorrendjét, vagy módosíthatja a partíciós sémát vagy a fájlcsoportot.

Ha az index kikényszerít egy PRIMARY KEY vagy UNIQUE több korlátozást, és az indexdefiníció semmilyen módon nem változik, a meglévő korlátozás megőrzése érdekében az index el lesz dobva, és újra létrejön. Ha azonban az indexdefiníció módosul, az utasítás meghiúsul. Egy PRIMARY KEY vagy UNIQUE több korlátozás definíciójának módosításához ejtse a kényszert, és adjon hozzá egy kényszert az új definícióhoz.

DROP_EXISTING javítja a teljesítményt, amikor újra létrehoz egy fürtözött indexet azonos vagy eltérő kulcskészlettel egy olyan táblán, amely szintén nemclustered indexekkel rendelkezik. DROP_EXISTING egy DROP INDEX utasítás végrehajtását váltja fel a régi fürtözött indexen, majd egy CREATE INDEX utasítás végrehajtása az új fürtözött indexhez. A nemclustered indexek egyszer újraépülnek, és csak akkor, ha az indexdefiníció módosult. A DROP_EXISTING záradék nem építi újra újra a nemclustered indexeket, ha az indexdefiníció ugyanazzal az indexnévvel, kulcs- és partícióoszlopokkal, egyediség attribútummal és rendezési sorrenddel rendelkezik, mint az eredeti index.

Függetlenül attól, hogy a nem kizárólagos indexek újra vannak-e felépítve, mindig az eredeti fájlcsoportokban vagy partíciós sémákban maradnak, és az eredeti partíciófüggvényeket használják. Ha egy fürtözött indexet egy másik fájlcsoportba vagy partíciós sémába újjáépítettek, a nemclustered indexek nem lesznek áthelyezve, hogy egybeesjenek a fürtözött index új helyével. Ezért még akkor is, ha a nemclustered indexek korábban a fürtözött indexhez igazodtak, előfordulhat, hogy már nem lesznek hozzá igazítva. A particionált indexek igazításáról további információt a particionált táblák és indexek című témakörben talál.

A DROP_EXISTING záradék nem rendezi újra az adatokat, ha ugyanazt az indexkulcsoszlopot ugyanabban a sorrendben és azonos növekvő vagy csökkenő sorrendben használja, kivéve, ha az indexelési utasítás nemclustered indexet ad meg, és a ONLINE beállítás OFFértéke . Ha a fürtözött index le van tiltva, a műveletet a CREATE INDEX WITH DROP_EXISTING következő beállítással ONLINEOFFkell végrehajtani: . Ha egy nemclustered index le van tiltva, és nincs letiltva fürtözött indexhez társítva, a CREATE INDEX WITH DROP_EXISTING művelet a következő értékre ONLINE állítható be OFF vagy ON.

Jegyzet

Ha a 128-as vagy annál nagyobb kiterjedésű indexeket elveti vagy újraépíti, az adatbázismotor a tényleges oldaleltéréseket és a hozzájuk tartozó zárolásokat a tranzakció véglegesítéséig hatástalanítja. További információ: Halasztott felszabadítási.

ONLINE lehetőség

Az indexműveletek online végrehajtására az alábbi irányelvek vonatkoznak:

Az alapul szolgáló tábla nem módosítható, csonkolt vagy elvethető, amíg egy online indexművelet folyamatban van.
Az indexművelet során további ideiglenes lemezterületre van szükség.
Online műveletek végrehajthatók olyan particionált indexeken és indexeken, amelyek tartósan számított oszlopokat vagy belefoglalt oszlopokat tartalmaznak.
Az WAIT_AT_LOW_PRIORITY argumentum beállítással eldöntheti, hogy az indexművelet hogyan halad, amikor zárolásra Sch-M vár. További információ: WAIT_AT_LOW_PRIORITY

További információ: Indexműveletek online végrehajtása.

Folytatható indexműveletek

Alkalmazható: SQL Server 2019 (15.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Az online index-létrehozási műveletet folytathatóvá teheti. Ez azt jelenti, hogy az index buildje leállítható, majd később újraindulhat attól a ponttól kezdve, ahol leállt. Ha újra felhasználhatóként szeretne futtatni egy index buildet, adja meg a RESUMABLE = ON lehetőséget.

Az újra felhasználható indexműveletekre az alábbi irányelvek vonatkoznak:

A RESUMABLE beállítás használatához a ONLINE lehetőséget is használnia kell.
A RESUMABLE beállítás nem marad meg egy adott index metaadataiban, és csak az aktuális DDL-utasítás időtartamára vonatkozik. Ezért a RESUMABLE = ON záradékot explicit módon kell megadni az újbóli használhatóság engedélyezéséhez.
A MAX_DURATION beállítás két környezetben adható meg:
- MAX_DURATION a RESUMABLE beállítás az újraépítés alatt álló index időintervallumát adja meg. Ez után az idő eltelt, és ha az index újraépítése továbbra is fut, az szüneteltetve lesz. Ön dönti el, hogy a szüneteltetett index újraépítése mikor folytatható. A MAX_DURATION időnek 0 percnél hosszabbnak kell lennie, és egy hétnél rövidebbnek vagy egyenlőnek kell lennie (7 * 24 * 60 = 10080 perc). Az indexműveletek hosszú szüneteltetése észrevehetően befolyásolhatja egy adott tábla DML-teljesítményét, valamint az adatbázis lemezkapacitását, mivel az eredeti index és az újonnan létrehozott index lemezterületet igényel, és a DML-műveleteknek frissíteniük kell. Ha MAX_DURATION beállítás nincs megadva, az indexművelet a befejezésig vagy a hiba bekövetkezéséig folytatódik.
- MAX_DURATION a WAIT_AT_LOW_PRIORITY beállításnál azt az időt adja meg, amíg az indexművelet le van tiltva, és a művelet végrehajtása előtt alacsony prioritású zárolásokat használjon. További információ: WAIT_AT_LOW_PRIORITY online indexműveletekkel.
Az indexművelet azonnali szüneteltetéséhez végrehajthatja a ALTER INDEX PAUSE parancsot, vagy végrehajthatja a KILL <session_id> parancsot.
Az eredeti CREATE INDEX utasítás ugyanazokkal a paraméterekkel való ismételt végrehajtása egy felfüggesztett index-létrehozási műveletet folytat. A szüneteltetett indexkészítési műveletet az utasítás végrehajtásával ALTER INDEX RESUME is folytathatja.
A ABORT parancs törli az index buildet futtató munkamenetet, és megszakítja az indexműveletet. Megszakított indexművelet nem folytatható.

A folytatható indexművelet addig fut, amíg befejeződik, szünetel vagy meghiúsul. Ha a művelet szünetel, hibaüzenet jelenik meg, amely azt jelzi, hogy a műveletet felfüggesztették, és hogy az index létrehozása nem fejeződött be. Ha a művelet meghiúsul, a rendszer hibát is kibocsát.

Annak ellenőrzéséhez, hogy egy indexművelet folytatható műveletként van-e végrehajtva, és az aktuális végrehajtási állapot ellenőrzéséhez használja a sys.index_resumable_operations katalógusnézetet.

Erőforrások

Az újra felhasználható indexműveletekhez a következő erőforrások szükségesek:

Az index létrehozásának fenntartásához további térközre van szükség, beleértve a létrehozás szüneteltetésére vonatkozó időt is.
További naplóteljesítmény a rendezési fázisban. Az újrahasználható index teljes naplóterület-kihasználtsága alacsonyabb a normál online index-létrehozáshoz képest, és lehetővé teszi a naplók csonkolását a művelet során.
Nem engedélyezettek a DDL-utasítások, amelyek megpróbálják módosítani a létrehozott indexhez társított táblát, miközben az indexművelet szünetel.
A ghost cleanup le van tiltva a buildben lévő indexen mind a szüneteltetett, mind a művelet futtatása közben.
Ha a tábla LOB oszlopokat tartalmaz, az újrakezdhető fürtözött indexek létrehozása sémamódosítási (Sch-M) zárolást igényel a művelet elején.

Jelenlegi funkcionális korlátozások

A folytatható index-létrehozási műveletekre a következő korlátozások vonatkoznak:

Az újrakezdhető online index létrehozási MAXDOP műveletének szüneteltetése után a kezdeti érték nem módosítható.
A SORT_IN_TEMPDB = ON beállítás nem támogatott az újraművelt indexműveletek esetében.
A RESUMABLE = ON rendelkező DDL-parancs nem hajtható végre explicit tranzakción belül.
Nem hozható létre újra felhasználható index, amely a következőket tartalmazza:
- Számított vagy timestamp (rowversion) oszlop(ok) kulcsoszlopként.
- LOB oszlop belefoglalt oszlopként.
A folytatható indexműveletek nem támogatottak:
- A ALTER INDEX REBUILD ALL parancs
- A ALTER TABLE REBUILD parancs
- Oszlopos adattárolású indexek
- Szűrt indexek
- Letiltott indexek

online indexelési műveletek WAIT_AT_LOW_PRIORITY

Érvényes: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance

Ha nem használja ezt a lehetőséget, a WAIT_AT_LOW_PRIORITY táblán vagy indexen zárolt összes aktív blokkoló tranzakciónak be kell fejeződnie ahhoz, hogy az index létrehozása művelet elinduljon és befejeződjön. Amikor az online indexművelet elindul, és a művelet befejeződik, be kell szereznie egy megosztott (S) vagy sémamódosítást (Sch-M) a táblára, és rövid ideig tárolnia kell. Annak ellenére, hogy a zárolás csak rövid ideig van tárolva, jelentősen befolyásolhatja a számítási feladat átviteli sebességét, növelheti a lekérdezés késését, vagy végrehajtási időtúllépéseket okozhat.

A problémák elkerülése érdekében a WAIT_AT_LOW_PRIORITY lehetőség lehetővé teszi az online indexművelet indításához és befejezéséhez szükséges S vagy Sch-M zárolások viselkedésének kezelését, három lehetőség közül választva. Minden esetben, ha a MAX_DURATION = n [minutes] által megadott várakozási idő alatt nincs olyan blokkolás, amely az indexművelettel jár, az indexművelet azonnal folytatódik.

WAIT_AT_LOW_PRIORITY az online indexelési műveletet alacsony prioritású zárolások használatával várja meg, így a normál prioritású zárolásokat használó egyéb műveletek addig is folytatva lesznek. A WAIT_AT_LOW_PRIORITY lehetőség kihagyása egyenértékű a WAIT_AT_LOW_PRIORITY (MAX_DURATION = 0 minutes, ABORT_AFTER_WAIT = NONE).

MAX_DURATION = idő [MINUTES]

Az a várakozási idő (percekben megadott egész szám), amelyet az online indexművelet alacsony prioritású zárolások használatával vár. Ha a művelet MAX_DURATION időre le van tiltva, a megadott ABORT_AFTER_WAIT műveletet hajtja végre. MAX_DURATION idő mindig percekben van, és a MINUTES szó kihagyható.

ABORT_AFTER_WAIT= [NONE | SELF | BLOCKERS ]

NONE: Folytassa a várakozást a normál prioritású zárolásra.
SELF: Lépjen ki az aktuálisan végrehajtott online indexműveletből anélkül, hogy bármilyen műveletet végrehajtanál. A SELF beállítás nem használható, ha MAX_DURATION 0.
BLOCKERS: Tiltsa le az összes olyan felhasználói tranzakciót, amely letiltja az online indexelési műveletet a művelet folytatásához. A BLOCKERS beállításhoz a CREATE INDEX vagy ALTER INDEX utasítást végrehajtó tagnak rendelkeznie kell a ALTER ANY CONNECTION engedéllyel.

A következő kiterjesztett események segítségével figyelheti az indexműveleteket, amelyek alacsony prioritású zárolásokra várnak:

lock_request_priority_state
process_killed_by_abort_blockers
ddl_with_wait_at_low_priority

Sor- és oldalzárolási beállítások

Ha ALLOW_ROW_LOCKS = ON és ALLOW_PAGE_LOCK = ON, sor-, oldal- és táblázatszintű zárolások engedélyezettek az index elérésekor. Az adatbázismotor kiválasztja a megfelelő zárolást, és eszkalálhatja a zárolást egy sor- vagy oldalzárolásról egy táblázatzárolásra.

Ha ALLOW_ROW_LOCKS = OFF és ALLOW_PAGE_LOCK = OFF, csak táblaszintű zárolás engedélyezett az index elérésekor.

Figyelmeztetés

Nem ajánlott letiltani a sor- vagy oldalzárolásokat egy indexen. Egyidejűséggel kapcsolatos problémák léphetnek fel, és előfordulhat, hogy bizonyos funkciók nem érhetők el. Az indexek például nem szervezhetők át, ha ALLOW_PAGE_LOCKSOFFvan beállítva.

Szekvenciális kulcsok

Érvényes: SQL Server 2019 (15.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabricben, valamint Azure SQL Managed Instance.

Az utolsó oldal beszúrásával kapcsolatos versengés gyakori teljesítményprobléma, amely akkor fordul elő, ha sok egyidejű szál próbál sorokat beszúrni egy szekvenciális kulccsal rendelkező indexbe. Az index akkor számít szekvenciálisnak, ha a kezdőkulcs oszlop olyan értékeket tartalmaz, amelyek mindig növekednek (vagy csökkennek), például egy identitásoszlopot vagy egy, az aktuális dátumra/időre alapértelmezett dátumot. Mivel a beszúrt kulcsok szekvenciálisak, az összes új sor az indexstruktúra végén lesz beszúrva – vagyis ugyanazon az oldalon. Ez a memóriában lévő lap versengéséhez vezet, amely több szálként figyelhető meg, amelyek arra várnak, hogy reteszelőt szerezzenek a szóban forgó oldalhoz. A megfelelő várakozási típus a következő PAGELATCH_EX: .

A OPTIMIZE_FOR_SEQUENTIAL_KEY index beállítás engedélyezése lehetővé teszi az adatbázismotoron belüli optimalizálást, amely segít javítani az átviteli sebességet a nagy egyidejűségű beszúrások esetében az indexbe. Olyan indexek számára készült, amelyek szekvenciális kulccsal rendelkeznek, és így hajlamosak az utolsó oldal beszúrására, de segíthetnek az olyan indexek esetében is, amelyek a B-Fa indexstruktúra más területein gyakori pontokat tartalmaznak.

Jegyzet

Adattömörítés

További információ az adattömörítésről: Adattömörítés.

Az adattömörítés használatakor az index buildelési műveleteinek kontextusában az alábbiakat érdemes figyelembe venni:

A tömörítéssel több sor tárolható egy lapon, de a maximális sorméretet nem módosítja.
Az index nem levéloldalai nem tömörített lapok, hanem sorsűríthetők.
Minden nemclustered index egyedi tömörítési beállítással rendelkezik, és nem örökli az alapul szolgáló tábla tömörítési beállítását.
Ha egy halomra fürtözött indexet hoz létre, a fürtözött index örökli a halom tömörítési állapotát, hacsak nincs megadva másik tömörítési állapot.

Annak kiértékeléséhez, hogy a tömörítési állapot módosítása hogyan befolyásolja a tábla, index vagy partíció által a térhasználatot, használja a sp_estimate_data_compression_savings tárolt eljárást.

XML-tömörítés

Érvényes: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance.

Az xml-tömörítésre számos adattömörítési szempont vonatkozik. A következő szempontokat is figyelembe kell vennie:

A partíciók listájának megadásakor az XML-tömörítés engedélyezhető az egyes partíciókon. Ha a partíciók listája nincs megadva, az összes partíció XML-tömörítésre van beállítva. Táblázat vagy index létrehozásakor az XML-adattömörítés le van tiltva, kivéve, ha másként van megadva. Ha módosít egy táblát, a meglévő tömörítés megmarad, kivéve, ha másként van megadva.
Ha megadja a partíciók vagy a tartományon kívüli partíciók listáját, a rendszer hibát okoz.
Ha egy halomra fürtözött indexet hoz létre, a fürtözött index örökli a halom XML-tömörítési állapotát, hacsak nincs megadva másik tömörítési beállítás.
A halom XML-tömörítési beállításának módosításához a táblában lévő összes nemclustered indexet újra kell felépíteni, hogy a halom új sorhelyeinek mutatói legyenek.
Az XML-tömörítést online vagy offline is engedélyezheti vagy letilthatja. A halom tömörítésének engedélyezése egyetlen szálon történik egy online művelethez.
A particionált táblák partícióinak XML-tömörítési állapotának meghatározásához használja a xml_compressionsys.partitions katalógusnézet oszlopát.

Indexstatisztikák

Sorkataszter létrehozásakor az adatbázismotor statisztikákat is létrehoz az index kulcsoszlopaihoz. A sys.stats katalógusnézetben a statisztikai objektum neve megegyezik az index nevével. Nem particionált indexek esetén a statisztikák az adatok teljes vizsgálatával jönnek létre. Particionált indexek esetén a statisztikák az alapértelmezett mintavételezési algoritmus használatával jönnek létre.

Oszlopcentrikus index létrehozásakor az adatbázismotor egy statisztikai objektumot is létrehoz a sys.statsban . Ez a statisztikai objektum nem tartalmaz olyan statisztikai adatokat, mint a hisztogram és a sűrűségvektor. Az adatbázis-klón létrehozásakor használatos az adatbázis szkriptelésével. Ekkor a rendszer az DBCC SHOW_STATISTICSUPDATE STATISTICS ... WITH STATS_STREAM oszloptár metaadatait, például a szegmenst, a szótárt és a deltatároló méretét szerzi be, és hozzáadja az oszlopcentrikus index statisztikáihoz. Ez a metaadatok dinamikusan lesznek lekértek egy normál adatbázis lekérdezés-fordítási idején, de az adatbázis-klónok statisztikai objektuma biztosítja. Az UPDATE STATISTICS parancs más forgatókönyvekben nem támogatott az oszlopcentrikus index statisztikai objektumához.

Engedélyek

ALTER A rögzített adatbázis-szerepkörhöz a táblán vagy a nézeten vagy tagságon db_ddladmin belüli engedély szükséges.

Korlátozások és korlátozások

Az Azure Synapse Analytics and Analytics Platform Systemben (PDW) nem hozhat létre:

Fürtözött vagy nem rendezett sortárindex egy adattárháztáblán, ha már létezik oszlopcentrikus index. Ez a viselkedés eltér az SMP SQL Servertől, amely lehetővé teszi, hogy a sor- és oszlopcentrikus indexek ugyanazon a táblán is létezhessenek.
Nem hozhat létre indexet egy nézetben.

Metaadatok

A meglévő indexekre vonatkozó információk megtekintéséhez lekérdezheti a sys.indexes katalógusnézetet.

Verziójegyzetek

Az Azure SQL Database és SQL adatbázis a Microsoft Fabric-ben nem támogat fájlcsoportokat, kivéve PRIMARY.
Az Azure SQL Database, SQL adatbázis a Microsoft Fabric-ben és Azure SQL Managed Instance nem támogatnak FILESTREAM opciókat.
Az oszlopcentrikus indexek nem érhetők el az SQL Server 2012 (11.x) előtt.
Az újraindítható indexműveletek elérhetők az SQL Server 2017-től (14.x) Azure SQL Database-ben, SQL adatbázisban Microsoft Fabric-ben, valamint Azure SQL Managed Instance-ban.

Példák: Minden verzió. Az AdventureWorks adatbázist használja

Egy. Egyszerű, nemclustered rowstore index létrehozása

Az alábbi példák nemclustered indexet hoznak létre a VendorID tábla Purchasing.ProductVendor oszlopában.

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. Egyszerű, nemclustered rowstore összetett index létrehozása

Az alábbi példa egy nemclustered összetett indexet hoz létre a SalesQuota tábla SalesYTD és Sales.SalesPerson oszlopán.

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

C. Index létrehozása táblán egy másik adatbázisban

Az alábbi példa egy fürtözött indexet hoz létre a VendorID tábla ProductVendor oszlopában az Purchasing adatbázisban.

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

D. Oszlop hozzáadása indexhez

Az alábbi példában az index IX_FF hoz létre két oszlopot a dbo-ból. FactFinance tábla. A következő utasítás egy újabb oszlopmal újraépíti az indexet, és megtartja a meglévő nevet.

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);

Példák: SQL Server, Azure SQL Database, SQL Database a Fabricben

E. Egyedi nemclustered index létrehozása

Az alábbi példa egy egyedi, nemclustered indexet hoz létre a Name tábla Production.UnitMeasure oszlopában az AdventureWorks2025 adatbázisban. Az index a Name oszlopba beszúrt adatok egyediségét kényszeríti ki.

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

Az alábbi lekérdezés az egyediségi kényszert úgy teszteli, hogy megpróbál beszúrni egy olyan sort, amelynek értéke megegyezik egy meglévő sor értékével.

-- 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());

Az eredményként kapott hibaüzenet a következő:

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. A IGNORE_DUP_KEY lehetőség használata

Az alábbi példa a IGNORE_DUP_KEY beállítás hatását mutatja be úgy, hogy több sort szúr be egy ideiglenes táblába először a ON beállítással, majd ismét a OFFbeállítással. A rendszer egyetlen sort szúr be a #Test táblába, amely szándékosan duplikált értéket okoz a második többsoros INSERT utasítás végrehajtásakor. A táblázat sorainak száma a beszúrt sorok számát adja vissza.

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

Íme a második INSERT utasítás eredménye.

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

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

Figyelje meg, hogy a Production.UnitMeasure táblából beszúrt olyan sorokat, amelyek nem szegték meg az egyediségi korlátozást, sikeresen beszúrták. Figyelmeztetést adott ki, és a duplikált sor figyelmen kívül lett hagyva, de a teljes tranzakció nem lett visszaállítva.

Ugyanezeket az utasításokat ismét végrehajtja a rendszer, de IGNORE_DUP_KEYOFFértékre van állítva.

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

Íme a második INSERT utasítás eredménye.

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

Figyelje meg, hogy a Production.UnitMeasure tábla egyik sora sem lett beszúrva a táblába, annak ellenére, hogy a tábla csak egy sora megsértette a UNIQUE indexkorlátot.

G. Index elvetése és újbóli létrehozása DROP_EXISTING használatával

Az alábbi példa egy meglévő indexet hoz létre a ProductID adatbázis Production.WorkOrder táblázatának AdventureWorks2025 oszlopában a DROP_EXISTING beállítással. A beállítások FILLFACTOR és PAD_INDEX is meg vannak adva.

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

H. Index létrehozása nézeten

Az alábbi példa egy nézetet és egy indexet hoz létre ezen a nézetben. A rendszer két lekérdezést tartalmaz, amelyek az indexelt nézetet használják.

-- 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

Én. Index létrehozása belefoglalt (nem kulcsos) oszlopokkal

Az alábbi példa egy nemclustered indexet hoz létre egy kulcsoszloptal (PostalCode) és négy nem kulcsoszloptal (AddressLine1, AddressLine2, City, StateProvinceID). Az index által lefedett lekérdezés a következő. A lekérdezésoptimalizáló által kiválasztott index megjelenítéséhez az SQL Server Management Studio Lekérdezés menüjében válassza a Tényleges végrehajtási terv megjelenítése a lekérdezés végrehajtása előtt.

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. Particionált index létrehozása

Az alábbi példa létrehoz egy nemclustered particionált indexet a TransactionsPS1, a AdventureWorks2025 adatbázis meglévő partíciós sémáján. Ez a példa feltételezi, hogy a particionált indexminta telepítve van.

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

K. Szűrt index létrehozása

Az alábbi példa egy szűrt indexet hoz létre az AdventureWorks2025 adatbázis Production.BillOfMaterials táblájában. A szűrő predikátum olyan oszlopokat is tartalmazhat, amelyek nem kulcsoszlopok a szűrt indexben. A példában szereplő predikátum csak azokat a sorokat jelöli ki, ahol az EndDate értéke nem NULL.

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

L. Tömörített index létrehozása

Az alábbi példa sortömörítéssel hoz létre indexet egy nem particionált táblán.

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

Az alábbi példa egy indexet hoz létre egy particionált táblán az index összes partícióján sortömörítés használatával.

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

Az alábbi példa egy indexet hoz létre egy particionált táblán az index partíciós 1 laptömörítésével, valamint az index 2 keresztül 4 partíciók sortömörítésével.

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. Index létrehozása XML-tömörítéssel

Érvényes: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és Azure SQL Managed Instance.

Az alábbi példa xml-tömörítéssel hoz létre indexet egy nem particionált táblán. Az index legalább egy oszlopának xml adattípusnak kell lennie.

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

Az alábbi példa egy indexet hoz létre egy particionált táblán xml-tömörítéssel az index összes partícióján.

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

N. Újrakezdhető indexműveletek létrehozása, folytatása, szüneteltetése és megszakítása

Alkalmazható: SQL Server 2019 (15.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és 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. INDEX LÉTREHOZÁSA különböző alacsony prioritású zárolási beállításokkal

Az alábbi példák a WAIT_AT_LOW_PRIORITY lehetőséget használják a blokkolás kezelésére szolgáló különböző stratégiák megadására.

--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

Az alábbi példa a RESUMABLE beállítást használja, és két MAX_DURATION értéket határoz meg, az első a ABORT_AFTER_WAIT beállításra, a második a RESUMABLE beállításra vonatkozik.

--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);

Példák: Azure Synapse Analytics and Analytics Platform System (PDW)

P. Alapszintű szintaxis

Újrakezdhető indexműveletek létrehozása, folytatása, szüneteltetése és megszakítása

Alkalmazható: SQL Server 2019 (15.x) és újabb verziók, Azure SQL Database, SQL adatbázis Microsoft Fabric-ben és 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. Nemclustered index létrehozása egy táblán az aktuális adatbázisban

Az alábbi példa egy nemclustered indexet hoz létre a VendorID tábla ProductVendor oszlopában.

CREATE INDEX IX_ProductVendor_VendorID
  ON ProductVendor (VendorID);

R. Fürtözött index létrehozása egy másik adatbázisban lévő táblán

Az alábbi példa egy nemclustered indexet hoz létre a VendorID tábla ProductVendor oszlopában az Purchasing adatbázisban.

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

S. Rendezett fürtözött index létrehozása táblán

Az alábbi példa egy rendezett fürtözött indexet hoz létre a c1 adatbázis c2 táblázatának T1 és MyDB oszlopán.

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

T. CCI átalakítása rendezett fürtözött indexké egy táblán

Az alábbi példa a meglévő fürtözött oszlopcentrikus indexet egy rendezett, MyOrderedCCI nevű fürtözött oszlopcentrikus indexké alakítja át a c1 és c2T2 tábla oszlopaiban az MyDB adatbázisban.

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

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-19

Megosztás a következőn keresztül:

INDEX LÉTREHOZÁSA (Transact-SQL)

Szintaxis

Szintaxis az SQL Serverhez, az Azure SQL Database-hez, az SQL Database-hez a Fabricben, az Azure SQL Managed Instance

Visszamenőlegesen kompatibilis relációs index

Az Azure Synapse Analytics és a párhuzamos adattárház szintaxisa

Érvek

EGYEDÜLÁLLÓ

FÜRTÖZÖTT

NEMCLUSTERED

index_name

oszlop

[ ASC | LEÍRÁS ]

INCLUDE (oszlop [ ,... n ] )

HOL <filter_predicate>

ON partition_scheme_name ( column_name )

A filegroup_name

ON [alapértelmezett]

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

<objektum>::=

database_name

schema_name

table_or_view_name

< >relational_index_option::=

PAD_INDEX = { ON | KI }

FILLFACTOR = fillfactor

SORT_IN_TEMPDB = { ON | KI }

IGNORE_DUP_KEY = { ON | KI }

STATISTICS_NORECOMPUTE = { ON | KI}

STATISTICS_INCREMENTAL = { ON | KI }

DROP_EXISTING = { ON | KI }

ONLINE = { ON | KI }

RESUMABLE = { ON | KI }

MAX_DURATION = idő [PERC] RESUMABLE = ON (ONLINE = ONszükséges)

ALLOW_ROW_LOCKS = { ON | KI }

ALLOW_PAGE_LOCKS = { ON | KI }

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | KI }

MAXDOP = max_degree_of_parallelism

DATA_COMPRESSION

XML_COMPRESSION

PARTÍCIÓKON ( { <partition_number_expression> | <tartomány> } [ ,...n ] )

Megjegyzések

Fürtözött indexek

Nemclustered indexek

Egyedi indexek

Particionált indexek

Szűrt indexek

A szűrt indexekhez szükséges SET-beállítások

Térbeli indexek

XML-indexek

Indexkulcs mérete

Számított oszlopok

Belefoglalt oszlopok az indexekbe

Indexbeállítások megadása

DROP_EXISTING záradék

ONLINE lehetőség

Folytatható indexműveletek

Erőforrások

Jelenlegi funkcionális korlátozások

online indexelési műveletek WAIT_AT_LOW_PRIORITY

Sor- és oldalzárolási beállítások

Szekvenciális kulcsok

Adattömörítés

XML-tömörítés

Indexstatisztikák

Engedélyek

Korlátozások és korlátozások

Metaadatok

Verziójegyzetek

Példák: Minden verzió. Az AdventureWorks adatbázist használja

Egy. Egyszerű, nemclustered rowstore index létrehozása

B. Egyszerű, nemclustered rowstore összetett index létrehozása

C. Index létrehozása táblán egy másik adatbázisban

D. Oszlop hozzáadása indexhez

Példák: SQL Server, Azure SQL Database, SQL Database a Fabricben

E. Egyedi nemclustered index létrehozása

F. A IGNORE_DUP_KEY lehetőség használata

G. Index elvetése és újbóli létrehozása DROP_EXISTING használatával

H. Index létrehozása nézeten

Én. Index létrehozása belefoglalt (nem kulcsos) oszlopokkal

MAX_DURATION = idő [PERC] `RESUMABLE = ON` (`ONLINE = ON`szükséges)