CREATE INDEX (Transact-SQL)

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Erstellt einen eindeutigen Index für eine Tabelle oder Sicht. Wird auch als Rowstore-Index bezeichnet, da es sich entweder um einen gruppierten oder nicht gruppierten B-Strukturindex handelt. Sie können noch bevor die Tabelle mit Daten aufgefüllt wird, einen Rowstore-Index erstellen. Verwenden Sie einen Rowstore-Index, um die Abfrageleistung zu verbessern, insbesondere, wenn die Abfragen aus bestimmten Spalten auswählen oder Werte erfordern, die in einer bestimmten Reihenfolge sortiert werden sollen.

Hinweis

In der Dokumentation wird der Begriff „B-Struktur“ im Allgemeinen in Bezug auf Indizes verwendet. In Zeilenspeicherindizes implementiert die Datenbank-Engine eine B+-Struktur. Dies gilt nicht für Columnstore-Indizes oder In-Memory-Datenspeicher. Weitere Informationen finden Sie im Leitfaden zur Architektur und zum Entwerfen von SQL Server- und Azure SQL-Indizes.

Azure Synapse Analytics und Analytics Platform System (PDW) unterstützen UNIQUE-Einschränkungen derzeit nicht. Beispiele, die auf eindeutige Einschränkungen verweisen, gelten nur für SQL Server, Azure SQL-Datenbank und azure SQL Managed Instance.

Informationen zu Indexentwurfsrichtlinien finden Sie im SQL Server-Indexentwurfshandbuch.

Beispiele:

1. Erstellen eines nicht gruppierten Index in einer Tabelle oder Ansicht

   CREATE INDEX index1 ON schema1.table1 (column1);
   

2. Erstellen eines gruppierten Index in einer Tabelle und Verwenden eines 3-teiligen Namens für die Tabelle

   CREATE CLUSTERED INDEX index1 ON database1.schema1.table1 (column1);
   

3. Erstellen eines nicht gruppierten Index mit einer UNIQUE-Einschränkung und Angeben der Sortierreihenfolge

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

Wichtiges Szenario:

Ab SQL Server 2016 (13.x) in der Azure SQL-Datenbank und in azure SQL Managed Instance können Sie einen nicht gruppierten Index für einen Columnstore-Index verwenden, um die Leistung von Data Warehouse-Abfragen zu verbessern. Weitere Informationen finden Sie unter Columnstore-Indizes – Data Warehouse.

Informationen zu weiteren Indextypen finden Sie unter:

• CREATE XML INDEX
• CREATE SPATIAL INDEX
• CREATE COLUMNSTORE INDEX

Transact-SQL-Syntaxkonventionen

Syntax

Syntax für SQL Server, Azure SQL-Datenbank und 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>

Abwärtskompatibler relationaler Index

Wichtig

Die abwärtskompatible Syntaxstruktur für den relationalen Index wird in einer zukünftigen Version von SQL Server entfernt. Verwenden Sie diese Syntaxstruktur beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen die Funktion aktuell verwendet wird. Verwenden Sie stattdessen die in <relational_index_option> angegebene Syntaxstruktur.

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

Argumente

UNIQUE

Erstellt einen eindeutigen Index für eine Tabelle oder Sicht. Ein eindeutiger Index ist ein Index, bei dem zwei Zeilen nicht den gleichen Indexschlüsselwert haben dürfen.

Das Datenbankmodul lässt das Erstellen eines eindeutigen Indexes für Spalten, die bereits doppelte Werte enthalten, nicht zuON, unabhängig davon, ob dieser Wert auf IGNORE_DUP_KEY festgelegt ist. Wenn dies versucht wird, zeigt das Datenbankmodul eine Fehlermeldung an. Doppelte Werte müssen entfernt werden, bevor ein eindeutiger Index für die Spalte oder Spalten erstellt werden kann.

Eine UNIQUE Einschränkung wird als Wert behandelt NULL . Wenn eine Spalte nullwertebar ist und eine UNIQUE Einschränkung für die Spalte vorhanden ist, ist höchstens eine Zeile mit einer NULL zulässig.

CLUSTERED

Erstellt einen Index, in dem die für die Indexschlüsselspalten angegebene Sortierreihenfolge die Seitenreihenfolge in der Indexstruktur auf dem Datenträger bestimmt. Zeilen auf den Seiten unten oder Blattebene des gruppierten Indexes enthalten immer alle Spalten der Tabelle. Zeilen auf den Seiten in den oberen Ebenen des Indexes enthalten nur Schlüsselspalten.

Eine Tabelle kann nur über einen gruppierten Index verfügen. Wenn ein gruppierter Index in einer Tabelle vorhanden ist, enthält er alle Daten in der Tabelle. Eine Tabelle ohne gruppierten Index wird als Heap bezeichnet.

Eine Sicht mit einem eindeutigen gruppierten Index wird als indizierte Sicht bezeichnet. Eine indizierte Ansicht kann nur einen gruppierten Index aufweisen. Durch das Erstellen eines eindeutigen gruppierten Index für eine Sicht wird die Sicht physisch materialisiert. Ein eindeutiger gruppierter Index muss für eine Sicht erstellt werden, bevor ein anderer Index für dieselbe Sicht definiert werden kann. Weitere Informationen finden Sie unter Erstellen von indizierten Ansichten.

Erstellen Sie den gruppierten Index, bevor Sie irgendeinen nicht gruppierten Index erstellen. Vorhandene nicht gruppierte Indizes für Tabellen werden neu erstellt, wenn ein gruppierter Index erstellt wird, bei dem es sich um einen ressourcenintensiven Vorgang handelt, wenn die Tabelle groß ist.

Falls CLUSTERED nicht angegeben ist, wird ein nicht gruppierter Index erstellt.

Hinweis

Da der gruppierte Index alle Daten in der Tabelle enthält, verschiebt das Erstellen eines gruppierten Indexes und die Verwendung der ON partition_scheme_name Klausel ON filegroup_name die Tabelle effektiv aus der Dateigruppe, in der die Tabelle erstellt wurde, in das neue Partitionsschema oder die Dateigruppe. Bevor Sie Tabellen oder Indizes für bestimmte Dateigruppen erstellen, überprüfen Sie, welche Dateigruppen verfügbar sind, und stellen Sie sicher, dass in ihnen ausreichend freier Speicherplatz für den Index vorhanden ist.

In einigen Fällen kann das Erstellen eines gruppierten Indexes zuvor deaktivierte Indizes aktivieren. Weitere Informationen finden Sie unter "Aktivieren von Indizes und Einschränkungen " und "Deaktivieren von Indizes und Einschränkungen".

NONCLUSTERED

Erstellt einen Index, in dem die für die Indexschlüsselspalten angegebene Sortierreihenfolge die Seitenreihenfolge in der Indexstruktur auf dem Datenträger bestimmt. Im Gegensatz zum gruppierten Index enthalten Zeilen auf den Seiten auf der Blattebene eines nicht gruppierten Indexes nur die Indexschlüsselspalten. Optional kann eine Teilmenge von Nichtschlüsselspalten mithilfe der INCLUDE Klausel eingeschlossen werden.

Jede Tabelle kann bis zu 999 nicht gruppierte Indizes aufweisen, unabhängig davon, wie die Indizes erstellt werden: entweder implizit mit den PRIMARY KEY Und UNIQUE Einschränkungen oder explizit mit CREATE INDEX.

Für indizierte Sichten können nicht gruppierte Indizes nur erstellt werden, wenn bereits ein eindeutiger gruppierter Index für die entsprechende Sicht definiert ist.

Wenn nicht anders angegeben, ist NONCLUSTERED der Standardindextyp.

index_name

Der Name des Index. Indexnamen müssen für eine Tabelle oder Sicht eindeutig sein, können aber innerhalb einer Datenbank mehrfach vorkommen. Indexnamen müssen den Regeln für Bezeichner entsprechen.

column

Gibt die Spalten an, auf denen der Index basiert. Geben Sie zwei oder mehr Spaltennamen an, um einen zusammengesetzten Index für die kombinierten Werte der angegebenen Spalten zu erstellen. Führen Sie die Spalten, die im zusammengesetzten Index enthalten sein sollen, in der Reihenfolge der Sortierpriorität in den Klammern hinter table_or_view_name auf.

Es können bis zu 32 Spalten in einem einzigen zusammengesetzten Indexschlüssel kombiniert werden. Alle Spalten in einem zusammengesetzten Indexschlüssel müssen sich in derselben Tabelle oder Sicht befinden. Die maximal zulässige Größe der kombinierten Indexwerte liegt bei 900 Byte für gruppierte Indizes oder 1700 Byte für nicht gruppierte Indizes. Für Versionen vor SQL-Datenbank und SQL Server 2016 (13.x) liegen die Höchstwerte bei 16 Spalten und 900 Byte.

Spalten mit den LOB-Datentypen (Large Object) ntext, text, varchar(max), nvarchar(max), varbinary(max), xml oder image können nicht als Schlüsselspalten für einen Index angegeben werden. Außerdem kann eine indizierte Ansichtsdefinition keine ntext-, Text- oder Bildspalten enthalten, auch wenn in der CREATE INDEX Anweisung nicht darauf verwiesen wird.

Sie können Indizes für Spalten mit dem CLR-benutzerdefinierten Typ erstellen, wenn durch den Typ Binärreihenfolgen unterstützt werden. Außerdem können Sie Indizes für berechnete Spalten erstellen, die als Methodenaufrufe aus einer Spalte mit dem benutzerdefinierten Typ definiert sind, vorausgesetzt, die Methoden sind als deterministisch markiert und führen keine Datenzugriffe durch. Weitere Informationen zum Indizieren von benutzerdefinierten CLR-Typspalten finden Sie unter benutzerdefinierte CLR-Typen.

[ ASC | DESC ]

Bestimmt für die entsprechende Indexspalte die aufsteigende oder absteigende Sortierreihenfolge. Der Standardwert ist ASC.

INCLUDE (column [ ,... n ] )

Gibt die Nichtschlüsselspalten an, die der Blattebene eines nicht gruppierten Indexes hinzugefügt werden sollen. Der nicht gruppierte Index kann eindeutig oder nicht eindeutig sein.

Spaltennamen können in der INCLUDE Liste nicht wiederholt werden und können nicht gleichzeitig als Schlüssel- und Nichtschlüsselspalten verwendet werden. Nicht gruppierte Indizes enthalten immer implizit die gruppierten Indexspalten, wenn ein gruppierter Index in der Tabelle definiert ist. Weitere Informationen finden Sie unter Erstellen von Indizes mit enthaltenen Spalten.

Mit Ausnahme von text, ntextund imagesind alle Datentypen zulässig. Beginnend mit SQL Server 2012 (11.x) in der Azure SQL-Datenbank und in azure SQL Managed Instance kann der Index mithilfe der ONLINE Option erstellt oder neu erstellt werden, wenn eine der angegebenen Nichtschlüsselspalten varchar(max), nvarchar(max) oder varbinary(max) datentypen ist.

Bei berechneten Spalten, die deterministisch und präzise oder unpräzise sind, kann es sich um eingeschlossene Spalten handeln. Berechnete Spalten, die von Bild,ntext, Text, varchar(max), nvarchar(max), varbinary(max) und XML-Datentypen abgeleitet werden können, solange der berechnete Spaltendatentyp als eingeschlossene Spalte zulässig ist. Weitere Informationen finden Sie unter "Indizes für berechnete Spalten".

Weitere Informationen zum Erstellen eines XML-Index finden Sie unter CREATE XML INDEX.

WHERE <filter_predicate>

Erstellt einen gefilterten Index, wobei angegeben wird, welche Zeilen in den Index aufgenommen werden sollen. Der gefilterte Index muss ein nicht gruppierter Index für eine Tabelle sein. Erstellt gefilterte Statistikdaten für die Datenzeilen im gefilterten Index.

Das Filterprädikat verwendet einfache Vergleichslogik und kann nicht auf eine berechnete Spalte, eine benutzerdefinierte Datentypspalte (UDT), eine Spalte mit räumlichem Datentyp oder eine Hierarchie-Datentypspalte verweisen. Vergleiche mit NULL Literalen, die die Vergleichsoperatoren verwenden, sind nicht zulässig. Verwenden Sie stattdessen die Operatoren IS NULL und IS NOT NULL.

Es folgen einige Beispiele für Filterprädikate für die Production.BillOfMaterials-Tabelle:

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

WHERE ComponentID IN (533, 324, 753)

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

Gefilterte Indizes gelten nicht für XML-Indizes und Volltextindizes. Bei UNIQUE Indizes müssen nur die ausgewählten Zeilen eindeutige Indexwerte aufweisen. Bei gefilterten Indizes ist die IGNORE_DUP_KEY-Option nicht zulässig.

ON partition_scheme_name ( column_name )

Gibt das Partitionsschema an, das die Dateigruppen definiert, denen die Partitionen eines partitionierten Index zugeordnet werden. Das Partitionsschema muss bereits durch Ausführen von CREATE PARTITION SCHEME oder ALTER PARTITION SCHEME in der Datenbank vorhanden sein. column_name gibt die Partitionierungsspalte für den Index an. Diese Spalte muss mit dem Datentyp, der Länge und der Genauigkeit des Arguments der Partitionsfunktion übereinstimmen, die partition_scheme_name verwendet. column_name ist nicht auf die Spalten in der Indexdefinition beschränkt. Jede Spalte in der Basistabelle kann angegeben werden, mit Ausnahme der Partitionierung eines eindeutigen Indexes , muss column_name aus denen ausgewählt werden, die als eindeutiger Schlüssel verwendet werden. Mit dieser Einschränkung kann Datenbank-Engine die Eindeutigkeit der Schlüsselwerte in nur einer einzigen Partition überprüfen.

Hinweis

Beim Partitionieren eines nicht eindeutigen gruppierten Index fügt Datenbank-Engine standardmäßig die Partitionierungsspalte zu der Liste der gruppierten Indexschlüssel hinzu, sofern sie dort noch nicht angegeben wurde. Beim Partitionieren eines nicht eindeutigen, nicht gruppierten Indexes fügt Datenbank-Engine die Partitionierungsspalte als (eingeschlossene) Nichtschlüsselspalte des Indexes hinzu, sofern sie noch nicht angegeben wurde.

Wenn partition_scheme_name oder filegroup bei einer partitionierten Tabelle nicht angegeben werden, wird der Index im selben Partitionsschema platziert, und er verwendet dieselbe Partitionierungsspalte wie die zugrunde liegende Tabelle.

Hinweis

Sie können kein Partitionierungsschema für einen XML-Index angeben. Beim Partitionieren der Basistabelle verwendet der XML-Index dasselbe Partitionsschema wie die Tabelle.

Weitere Informationen zum Partitionieren von Indizes, partitionierten Tabellen und Indizes.

ON filegroup_name

Erstellt den angegebenen Index für die angegebene Dateigruppe. Wenn kein Speicherort angegeben wurde und die Tabelle oder Sicht nicht partitioniert ist, verwendet der Index dieselbe Dateigruppe wie die zugrunde liegende Tabelle oder Sicht. Die Dateigruppe muss bereits vorhanden sein.

ON [Standard]

Erstellt den angegebenen Index in derselben Dateigruppe oder in demselben Partitionsschema wie die Tabelle oder Sicht.

Der Begriff defaultist in diesem Kontext kein Schlüsselwort. Es handelt sich um einen Bezeichner für das Dateigruppen- oder partitionierte Schema der Tabelle oder Ansicht und muss wie in ON "default" oder ON [default]. Wenn "default" angegeben, muss die QUOTED_IDENTIFIER Option für die aktuelle Sitzung sein ON . Dies ist die Standardeinstellung. Weitere Informationen finden Sie unter SET QUOTED_IDENTIFIER.

Hinweis

Geben Sie im Kontext von CREATE INDEX, "default" und [default] geben Sie nicht die Standarddateigruppe der Datenbank an. Sie geben das Dateigruppen- oder Partitionsschema an, das von der Basistabelle oder -ansicht verwendet wird. Dies unterscheidet sich von , wo CREATE TABLE"default" und [default] platzieren Sie die Tabelle in der Standarddateigruppe der Datenbank.

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

Gibt die Platzierung der FILESTREAM-Daten für die Tabelle an, wenn ein gruppierter Index erstellt wird. Die FILESTREAM_ON-Klausel lässt zu, dass FILESTREAM-Daten in eine andere FILESTREAM-Dateigruppe oder ein anderes Partitionsschema verschoben werden.

Der filestream_filegroup_name ist der Name einer FILESTREAM-Dateigruppe. Für die Dateigruppe muss eine Datei mit einer CREATE DATABASE-Anweisung oder einer ALTER DATABASE-Anweisung definiert worden sein, andernfalls wird ein Fehler ausgelöst.

Wenn die Tabelle partitioniert ist, muss die FILESTREAM_ON-Klausel eingeschlossen werden und ein Partitionsschema von FILESTREAM-Dateigruppen angeben, das die gleiche Partitionsfunktion und die gleichen Partitionsspalten wie das Partitionsschema der Tabelle enthält. Andernfalls wird ein Fehler ausgelöst.

Wenn die Tabelle nicht partitioniert ist, kann die FILESTREAM-Spalte nicht partitioniert werden. Die FILESTREAM-Daten für die Tabelle müssen in einer einzigen Dateigruppe gespeichert werden, die in der FILESTREAM_ON-Klausel angegeben wird.

FILESTREAM_ON NULL kann in einer CREATE INDEX-Anweisung angegeben werden, wenn ein gruppierter Index erstellt wird und die Tabelle keine FILESTREAM-Spalte enthält.

Weitere Informationen finden Sie unter FILESTREAM (SQL Server).

<object>::=

Das vollqualifizierte oder nicht vollqualifizierte Objekt, das indiziert werden soll.

database_name

Der Name der Datenbank.

schema_name

Der Name des Schemas, zu dem die Tabelle oder Sicht gehören.

table_or_view_name

Der Name der Tabelle oder Sicht, die indiziert werden soll.

Um einen Index für eine Ansicht zu erstellen, muss die Ansicht mit SCHEMABINDINGdefiniert werden. Ein eindeutiger gruppierter Index muss für eine Sicht erstellt werden, bevor ein nicht gruppierter Index erstellt wird. Weitere Informationen zu indizierten Ansichten finden Sie in den Hinweisen.

Ab SQL Server 2016 (13.x) kann es sich bei dem Objekt um eine Tabelle handeln, die gemeinsam mit einem gruppierten Columnstore-Index gespeichert wird.

Azure SQL-Datenbank unterstützt das dreiteilige Namensformat <database_name>.<schema_name>.<object_name>, wenn <database_name> der aktuelle Datenbankname ist, oder <database_name>tempdb ist und <object_name> mit # oder ##beginnt. Wenn der Schemaname dboist, kann <schema_name> weggelassen werden.

<relational_index_option>::=

Gibt die Optionen an, die beim Erstellen des Indexes verwendet werden sollen.

PAD_INDEX = { ON | OFF }

Gibt die Auffüllung von Indizes an. Der Standardwert ist OFF.

• EIN

  Der Prozentsatz des freien Speicherplatzes, der durch den Füllfaktor angegeben wird, wird auf die Seiten der Mittleren Ebene des Indexes angewendet. Wenn FILLFACTOR nicht gleichzeitig angegeben wird, PAD_INDEX auf ONfestgelegt ist, wird der Füllfaktorwert in sys.indexes verwendet.

• OFF

  Die Zwischenebenenseiten sind nahezu vollständig aufgefüllt. Allerdings ist ausreichend Speicherplatz vorhanden, um mindestens eine Zeile in der maximal für den Index möglichen Größe aufzunehmen, wenn der Schlüsselsatz auf den Zwischenseiten berücksichtigt wird. Dies tritt auch auf, wenn PAD_INDEX auf ON festgelegt ist, aber der Füllfaktor nicht angegeben ist.

Die PAD_INDEX Option ist nur dann nützlich, wenn FILLFACTOR sie angegeben wird, da PAD_INDEX der durch FILLFACTOR. Wenn der angegebene FILLFACTOR Prozentsatz nicht groß genug ist, um eine Zeile zuzulassen, überschreibt das Datenbankmodul intern den Prozentsatz, um das Minimum zuzulassen. Die Anzahl der Zeilen auf einer Zwischenindexseite ist nie kleiner als zwei, unabhängig davon, wie niedrig der Wert ist FILLFACTOR.

In abwärtskompatibler Syntax entspricht WITH PAD_INDEXWITH PAD_INDEX = ON.

FILLFACTOR = fillfactor

Gibt einen Prozentsatz an, der angibt, wie weit das Datenbank-Engine die Blattebene jeder Indexseite während der Indexerstellung oder -neuerstellung füllen soll. Der Füllfaktorwert muss ein ganzzahliger Wert zwischen 1 und 100 sein. Die Füllfaktorwerte 0 und 100 sind in jeder Hinsicht identisch. Wenn fillfactor 100 ist, erstellt das Datenbank-Engine Indizes mit vollständig aufgefüllten Blattseiten.

Die FILLFACTOR-Einstellung gilt nur, wenn der Index erstellt oder neu erstellt wird. Die Datenbank-Engine hält den angegebenen Prozentsatz des Speicherplatzes auf den Seiten nicht dynamisch frei.

Verwenden Sie die Spalte in der Sys.indexes-Katalogansicht, um die Einstellung für den fill_factor Füllfaktor anzuzeigen.

Wichtig

Das Erstellen eines Indexes mit einer FILLFACTOR kleiner als 100 erhöht den Speicherplatz, den die Daten belegen, da das Datenbankmodul die Daten entsprechend dem Füllfaktor neu verteilt, wenn ein Index erstellt oder neu erstellt wird.

Weitere Informationen finden Sie unter Angeben des Füllfaktors für einen Index.

SORT_IN_TEMPDB = { ON | OFF }

Gibt an, ob temporäre Sortierergebnisse in tempdbgespeichert werden sollen. Der Standardwert ist OFF mit Ausnahme von Azure SQL-Datenbank Hyperscale. Für alle Indexbuildvorgänge in Hyperscale wird SORT_IN_TEMPDB immer ON, es sei denn, ein reaktivierbarer Indexbuild wird verwendet. Für reaktivierbare Indexbuilds ist SORT_IN_TEMPDB immer OFF.

• EIN

  Die Zwischensortierungsergebnisse, die zum Erstellen des Indexes verwendet werden, werden in tempdbgespeichert. Dies kann die Zeit verringern, die zum Erstellen eines Indexes erforderlich ist. Sie erhöht jedoch den Betrag an Speicherplatz, der während der Indexerstellung verwendet wird.

• OFF

  Die Zwischenergebnisse der Sortierung werden in derselben Datenbank gespeichert wie der Index.

Zusätzlich zum erforderlichen Speicherplatz in der Benutzerdatenbank zum Erstellen des Indexes muss etwa die gleiche Menge an zusätzlichem Speicherplatz vorhanden sein, tempdb um die Zwischensortierungsergebnisse zu speichern. Weitere Informationen finden Sie unter SORT_IN_TEMPDB Option für Indizes.

In abwärtskompatibler Syntax entspricht WITH SORT_IN_TEMPDBWITH SORT_IN_TEMPDB = ON.

IGNORE_DUP_KEY = { ON | OFF }

Gibt die Fehlermeldung an, wenn ein Einfügevorgang versucht, doppelte Schlüsselwerte in einen eindeutigen Index einzufügen. Die IGNORE_DUP_KEY-Option gilt nur für Einfügevorgänge nach dem Erstellen oder Neuerstellen des Index. Beim Ausführen von CREATE INDEX, ALTER INDEX oder UPDATE hat die Option keine Auswirkungen. Der Standardwert ist OFF.

• EIN

  Eine Warnmeldung wird ausgegeben, wenn doppelte Schlüsselwerte in einen eindeutigen Index eingefügt werden. Nur die Zeilen, die die Eindeutigkeitseinschränkung verletzen, werden nicht eingefügt.

• OFF

  Eine Fehlermeldung wird ausgegeben, wenn doppelte Schlüsselwerte in einen eindeutigen Index eingefügt werden. Die gesamte INSERT Anweisung wird zurückgesetzt.

IGNORE_DUP_KEY kann nicht für Indizes festgelegt ON werden, die in einer Ansicht, nicht eindeutigen Indizes, XML-Indizes, räumlichen Indizes und gefilterten Indizes erstellt wurden.

Zum Anzeigen der IGNORE_DUP_KEY Einstellung für einen Index verwenden Sie die ignore_dup_key Spalte in der sys.indexes Katalogansicht.

In abwärtskompatibler Syntax entspricht WITH IGNORE_DUP_KEYWITH IGNORE_DUP_KEY = ON.

STATISTICS_NORECOMPUTE = { ON | OFF}

Gibt an, ob Statistiken neu komputiert werden. Der Standardwert ist OFF.

• EIN

  Veraltete Indexstatistiken werden nicht automatisch neu berechnet.

• OFF

  Die automatischen Updates der Statistiken sind aktiviert.

Wenn Sie die automatische Aktualisierung von Statistiken wiederherstellen möchten, legen Sie STATISTICS_NORECOMPUTE auf OFF fest oder führen Sie die UPDATE STATISTICS-Anweisung ohne die NORECOMPUTE-Klausel aus.

Warnung

Wenn Sie die automatische Neukompilierung von Statistiken deaktivieren, indem Sie STATISTICS_NORECOMPUTE = ONfestlegen, können Sie verhindern, dass der Abfrageoptimierer optimale Ausführungspläne für Abfragen mit der Tabelle auswählt.

Das Festlegen STATISTICS_NORECOMPUTE auf ON verhindert nicht die Aktualisierung von Indexstatistiken, die während des Indexerstellungsvorgangs auftreten.

In abwärtskompatibler Syntax entspricht WITH STATISTICS_NORECOMPUTEWITH STATISTICS_NORECOMPUTE = ON.

STATISTICS_INCREMENTAL = { ON | OFF }

gilt für: SQL Server 2014 (12.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

Wenn ONdie erstellten Statistiken pro Partitionsstatistik vorliegen. Wenn OFFdie Statistikstruktur verworfen wird und SQL Server die Statistiken neu berechnet. Der Standardwert ist OFF.

Wenn Statistiken pro Partition nicht unterstützt werden, wird die Option ignoriert und eine Warnung generiert. In den folgenden Fällen werden inkrementelle Statistiken nicht unterstützt:

• Statistiken, die mit Indizes erstellt wurden, die über keine Partitionsausrichtung mit der Basistabelle verfügen.
• Statistiken, die für lesbare sekundäre Always On-Datenbanken erstellt wurden.
• Statistiken, die für schreibgeschützte Datenbanken erstellt wurden.
• Statistiken, die für gefilterte Indizes erstellt wurden.
• Statistiken, die für Sichten erstellt wurden.
• Statistiken, die für interne Tabellen erstellt wurden.
• Statistiken, die mit räumlichen Indizes oder XML-Indizes erstellt wurden.

DROP_EXISTING = { ON | OFF }

Eine Option zum Entfernen und erneutem Erstellen eines vorhandenen gruppierten oder nicht gruppierten Index mit veränderten Spaltenspezifikationen, die den Namen für den Index beibehält. Der Standardwert ist OFF.

• EIN

  Gibt an, dass der vorhandene Index entfernt und neu erstellt werden soll. Der Index muss über denselben Namen wie der Parameter index_name verfügen.

• OFF

  Gibt an, dass der vorhandene Index nicht entfernt und neu erstellt werden soll. SQL Server zeigt einen Fehler an, wenn der angegebene Indexname bereits vorhanden ist.

Mit DROP_EXISTING können Sie Folgendes ändern:

• Umwandlung eines nicht gruppierten Rowstore-Index in einen gruppierten Rowstore-Index.

Sie können mit DROP_EXISTING Folgendes nicht ändern:

• Umwandlung eines gruppierten Rowstore-Index in einen nicht gruppierten Rowstore-Index.
• Umwandlung eines gruppierten Columnstore-Index in einen nicht gruppierten Rowstore-Index.

In abwärtskompatibler Syntax entspricht WITH DROP_EXISTINGWITH DROP_EXISTING = ON.

ONLINE = { ON | OFF }

Gibt an, ob die zugrunde liegenden Tabellen und zugeordneten Indizes für Abfragen und Datenänderungen während des Indexvorgangs verfügbar sind. Der Standardwert ist OFF.

Wichtig

Onlineindexvorgänge sind nicht in jeder Edition von Microsoft SQL Serververfügbar. Eine Liste der Funktionen, die von den SQL Server-Editionen unterstützt werden, finden Sie unter Editionen und unterstützte Funktionen von SQL Server 2022.

• EIN

  Lang andauernde Sperren werden nicht für die Dauer des Indexvorgangs aufrechterhalten. Während der Hauptphase des Indexvorgangs wird nur eine Absichtssperre (IS) in der Quelltabelle gespeichert. Dadurch können Abfragen oder Updates für die zugrunde liegende Tabelle und die Indizes fortgesetzt werden. Zu Beginn des Vorgangs wird eine freigegebene (S) Sperre für das Quellobjekt für einen kurzen Zeitraum aufbewahrt. Am Ende des Vorgangs wird für einen kurzen Zeitraum eine freigegebene (S) Sperre für das Objekt abgerufen, wenn ein nicht gruppierter Index erstellt wird. Eine Schemaänderung (Sch-M) wird abgerufen, wenn ein gruppierter Index online erstellt oder abgelegt wird und ein gruppierter oder nicht gruppierter Index neu erstellt wird. ONLINE kann nicht festgelegt ON werden, wenn ein Index in einer lokalen temporären Tabelle erstellt wird.

  Hinweis

  Sie können die Option WAIT_AT_LOW_PRIORITY verwenden, um die Blockierung während Onlineindexvorgängen zu reduzieren oder zu vermeiden. Weitere Informationen finden Sie unter WAIT_AT_LOW_PRIORITY mit Onlineindexvorgängen.

• OFF

  Die Tabellensperren werden für die Dauer des Indexvorgangs angewendet. Ein Offlineindexvorgang, der einen gruppierten, räumlichen oder XML-Index erstellt, neu erstellt, neu erstellt oder abbricht, einen nicht gruppierten Index erstellt, neu erstellt oder abbricht, erhält eine Schemaänderung (Sch-M) Sperre für die Tabelle. Dadurch wird verhindert, dass Benutzer für die Dauer des Vorgangs auf die zugrunde liegende Tabelle zugreifen können. Ein Offlineindexvorgang, der einen nicht gruppierten Index erstellt, erwirbt zunächst eine freigegebene (S) Sperre für die Tabelle. Dies verhindert Änderungen der zugrunde liegenden Tabellendefinition, ermöglicht jedoch das Lesen und Ändern der Daten in der Tabelle, während der Indexbuild ausgeführt wird.

Weitere Informationen finden Sie unter Ausführen von Indexvorgängen online und Richtlinien für Onlineindexvorgänge.

Indizes, einschließlich Indizes globaler temporärer Tabellen, können online erstellt werden. Es gelten folgende Ausnahmen:

• XML-Index
• Index für eine lokale temp-Tabelle
• Eindeutiger gruppierter Ausgangsindex für eine Sicht
• Deaktivierte gruppierte Indizes
• Gruppierte Spaltenspeicherindizes in SQL Server 2017 (14.x)) und älteren Versionen
• Nicht gruppierte Spaltenspeicherindizes in SQL Server 2016 (13.x)) und älteren Versionen
• Gruppierter Index, wenn die zugrunde liegende Tabelle LOB-Datentypen (image, ntext, text) und räumliche Datentypen enthält.
• varchar(max)- und varbinary(max)-Spalten können nicht Teil eines Indexschlüssels sein. In SQL Server (beginnend mit SQL Server 2012 (11.x)), in Azure SQL-Datenbank und in azure SQL Managed Instance, wenn eine Tabelle varchar(max) oder varbinary(max)- Spalten enthält, kann ein gruppierter Index, der andere Spalten enthält, mithilfe der ONLINE Option erstellt oder neu erstellt werden.
• Nicht gruppierte Indizes für eine Tabelle mit einem gruppierten Spaltenspeicherindex

Weitere Informationen finden Sie unter Funktionsweise von Onlineindexvorgängen.

RESUMABLE = { ON | OFF }

gilt für: SQL Server 2019 (15.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

Gibt an, ob ein Onlineindexvorgang fortsetzbar ist. Weitere Informationen finden Sie unter Resumable index operations and Resumable index considerations.

• EIN

  Der Indexvorgang ist fortsetzbar.

• OFF

  Der Indexvorgang ist nicht fortsetzbar.

MAX_DURATION = time [MINUTEN]; wird mit RESUMABLE = ON verwendet (erfordert ONLINE = ON)

gilt für: SQL Server 2019 (15.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

Gibt an, wie lange in Minuten ein reaktivierbarer Indexvorgang ausgeführt wird, bevor er angehalten wird.

ALLOW_ROW_LOCKS = { ON | OFF }

Gibt an, ob Zeilensperren zulässig sind. Der Standardwert ist ON.

• EIN

  Zeilensperren sind beim Zugriff auf den Index zulässig. Das Datenbank-Engine bestimmt, wann Zeilensperren verwendet werden.

• OFF

  Zeilensperren werden nicht verwendet.

ALLOW_PAGE_LOCKS = { ON | OFF }

Gibt an, ob Seitensperren zulässig sind. Der Standardwert ist ON.

• EIN

  Seitensperren sind beim Zugriff auf den Index zulässig. Das Datenbank-Engine bestimmt, wann Seitensperren verwendet werden.

• OFF

  Seitensperren werden nicht verwendet.

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | OFF }

gilt für: SQL Server 2019 (15.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

Gibt an, ob eine Optimierung erforderlich ist, um den Inhalt der letzten Seite zu vermeiden. Der Standardwert ist OFF. Weitere Informationen finden Sie im Abschnitt "Sequenzielle Schlüssel ".

MAXDOP = max_degree_of_parallelism

Überschreibt den maximalen Grad an Parallelität Konfigurationsoption für den Indexvorgang. Weitere Informationen finden Sie unter Konfigurieren der Serverkonfigurationsoption Max. Grad an Parallelität. Verwenden Sie MAXDOP, um den Grad der Parallelität und den resultierenden Ressourcenverbrauch für einen Indexbuildvorgang zu begrenzen.

max_degree_of_parallelism kann folgende Werte haben:

• 1

  Unterdrückt das Generieren paralleler Pläne.

• >1

  Schränkt den maximalen Grad der Parallelität ein, der in einem parallelen Indexvorgang auf die angegebene Zahl oder weniger basierend auf der aktuellen Systemauslastung verwendet wird.

• 0 (Standard)

  Verwendet den Grad der Parallelität, die auf Server-, Datenbank- oder Workloadgruppenebene angegeben ist, es sei denn, dies ist auf der Grundlage der aktuellen Systemauslastung reduziert.

Weitere Informationen finden Sie unter Konfigurieren von parallelen Indexvorgängen.

Hinweis

Parallele Indexvorgänge sind nicht in jeder Edition von Microsoft SQL Server verfügbar. Eine Liste der Funktionen, die von den SQL Server-Editionen unterstützt werden, finden Sie unter Editionen und unterstützte Funktionen von SQL Server 2022.

DATA_COMPRESSION

Gibt die Datenkomprimierungsoption für den angegebenen Index, die Partitionsnummer oder den Bereich von Partitionen an. Die folgenden Optionen sind verfügbar:

• Keine

  Der Index oder die angegebenen Partitionen werden nicht komprimiert. Dies gilt nicht für Columnstore-Indizes.

• ROW

  Der Index oder die angegebenen Partitionen werden mit Zeilenkomprimierung komprimiert. Dies gilt nicht für Columnstore-Indizes.

• PAGE

  Der Index oder die angegebenen Partitionen werden mit Seitenkomprimierung komprimiert. Dies gilt nicht für Columnstore-Indizes.

• COLUMNSTORE

  gilt für: SQL Server 2014 (12.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

  Gilt nur für columnstore-Indizes, einschließlich nicht gruppierter und gruppierter columnstore-Indizes.

• COLUMNSTORE_ARCHIVE

  gilt für: SQL Server 2014 (12.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

  Gilt nur für columnstore-Indizes, einschließlich nicht gruppierter und gruppierter columnstore-Indizes. COLUMNSTORE_ARCHIVE komprimiert die angegebene Partition weiter auf eine kleinere Größe. Dies empfiehlt sich bei der Archivierung und in Situationen, in denen es auf eine geringere Speichergröße und nicht auf den zusätzlichen Zeitaufwand für das Speichern und Abrufen ankommt.

Weitere Informationen zur Komprimierung finden Sie unter Datenkomprimierung.

XML_COMPRESSION

gilt für: SQL Server 2022 (16.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

Gibt die XML-Komprimierungsoption für den angegebenen Index an, der mindestens eine Spalte vom XML-Datentyp enthält. Die folgenden Optionen sind verfügbar:

• EIN

  Der Index oder die angegebenen Partitionen werden mit der XML-Komprimierung komprimiert.

• OFF

  Index- oder angegebene Partitionen werden nicht mithilfe der XML-Komprimierung komprimiert.

ON PARTITIONS ( { <partition_number_expression> | <range> } [ ,...n ] )

Gibt die Partitionen an, für die die Einstellung DATA_COMPRESSION oder XML_COMPRESSION gilt. Wenn der Index nicht partitioniert ist, generiert das ON PARTITIONS Argument einen Fehler. Wenn die ON PARTITIONS-Klausel nicht angegeben wird, gilt die DATA_COMPRESSION- oder XML_COMPRESSION-Option für alle Partitionen eines partitionierten Index.

<partition_number_expression> kann wie folgt angegeben werden:

• Geben Sie die Nummer für eine Partition an, beispielsweise: ON PARTITIONS (2).
• Geben Sie die Partitionsnummern für mehrere einzelne Partitionen durch Kommas getrennt an, beispielsweise: ON PARTITIONS (1, 5).
• Geben Sie sowohl Bereiche als auch einzelne Partitionen an, beispielsweise: ON PARTITIONS (2, 4, 6 TO 8).

<range> kann als Partitionsnummern angegeben werden, die durch das Schlüsselwort TOgetrennt sind, z. B.: ON PARTITIONS (6 TO 8).

Wenn Sie für verschiedene Partitionen unterschiedliche Datenkomprimierungstypen festlegen möchten, geben Sie die Option DATA_COMPRESSION mehrmals an, beispielsweise:

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

Sie können die Option XML_COMPRESSION auch mehrmals angeben. Beispiel:

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

Bemerkungen

Beim Erstellen des Abfrageplans für die CREATE INDEX Anweisung kann sich der Abfrageoptimierer entscheiden, einen anderen Index zu scannen, anstatt einen Tabellenscan durchzuführen. Der Sortiervorgang kann in einigen Situationen beseitigt werden. Auf Multiprozessorcomputern können Parallelität für die Scan- und Sortiervorgänge verwendet werden, CREATE INDEX die mit der Erstellung des Indexes verknüpft sind, auf die gleiche Weise wie andere Abfragen. Weitere Informationen finden Sie unter Konfigurieren von parallelen Indexvorgängen.

Der CREATE INDEX Vorgang kann minimal protokolliert werden, wenn das Datenbankwiederherstellungsmodell entweder auf "Massenprotokoll" oder "einfach" festgelegt ist.

Indizes können für temporäre Tabellen erstellt werden. Wenn die Tabelle verworfen oder außerhalb des Gültigkeitsbereichs liegt, werden die Indizes gelöscht.

Ein gruppierter Index basiert auf einer Tabellenvariable, wenn eine Primärschlüsseleinschränkung hinzugefügt wird. Ebenso basiert ein nicht gruppierter Index auf einer Tabellenvariablen, wenn eine eindeutige Einschränkung hinzugefügt wird. Wenn die Tabellenvariable außerhalb des Gültigkeitsbereichs ist, werden die Indizes gelöscht.

Durch Indizes werden erweiterte Eigenschaften unterstützt.

CREATE INDEX wird in Microsoft Fabric nicht unterstützt.

Gruppierte Indizes

Für das Erstellen eines gruppierten Index für eine Tabelle (Heap) oder das Löschen und Neuerstellen eines vorhandenen gruppierten Index muss zusätzlicher Arbeitsbereich in der Datenbank verfügbar sein, um das Sortieren von Daten und das Speichern einer temporären Kopie der ursprünglichen Tabelle oder von vorhandenen gruppierten Indexdaten zu ermöglichen. Weitere Informationen zu gruppierten Indizes finden Sie unter Erstellen von gruppierten Indizes und der SQL Server-Indexarchitektur und -Entwurfsanleitung.

Nicht gruppierte Indizes

Ab SQL Server 2016 (13.x) in der Azure SQL-Datenbank und in azure SQL Managed Instance können Sie einen nicht gruppierten Index für eine Tabelle erstellen, die als gruppierter Spaltenspeicherindex gespeichert ist. Wenn Sie zuerst einen nicht gruppierten Index für eine Tabelle erstellen, die als Heap oder gruppierter Index gespeichert ist, wird der Index beibehalten, wenn Sie die Tabelle später in einen gruppierten Columnstore-Index konvertieren. Außerdem ist es nicht notwendig, den nicht gruppierten Index zu löschen, wenn Sie den gruppierten Columnstore-Index neu erstellen.

Die FILESTREAM_ON-Option gilt nicht, wenn Sie einen nicht gruppierten Index für eine Tabelle erstellen, die als gruppierter Columnstore-Index gespeichert wurde.

Eindeutige Indizes

Wenn ein eindeutiger Index vorhanden ist, sucht das Datenbankmodul jedes Mal, wenn Daten hinzugefügt oder geändert werden, auf doppelte Werte. Vorgänge, die doppelte Schlüsselwerte generieren würden, werden zurückgesetzt, und das Datenbankmodul gibt eine Fehlermeldung zurück. Dies gilt auch dann, wenn der Datenzugabe- oder Änderungsvorgang viele Zeilen ändert, aber nur ein Duplikat verursacht. Wenn versucht wird, Zeilen einzufügen, wenn ein eindeutiger Index vorhanden ist, auf den die IGNORE_DUP_KEY Option festgelegt ONist, werden die Zeilen, die gegen den eindeutigen Index verstoßen, ignoriert.

Partitionierten Indizes

Partitionierte Indizes werden ähnlich wie partitionierte Tabellen erstellt und verwaltet. Aber wie gewöhnliche Indizes werden sie wie separate Datenobjekte behandelt. Sie können einen partitionierten Index für eine nicht partitionierte Tabelle erstellen, und Sie können einen nicht partitionierten Index für eine partitionierte Tabelle erstellen.

Wenn Sie einen Index für eine partitionierte Tabelle erstellen und keine Dateigruppe angeben, in die der Index platziert werden soll, wird der Index auf die gleiche Weise partitioniert wie die zugrunde liegende Tabelle. Der Grund hierfür ist, dass Indizes standardmäßig in dieselben Dateigruppen wie die zugrunde liegenden Tabellen platziert werden. Bei partitionierten Tabellen werden Indizes in dasselbe Partitionsschema platziert, das dieselben Partitionierungsspalten verwendet. Wenn der Index das gleiche Partitionsschema und die gleiche Partitionierungsspalte wie die Tabelle verwendet, wird der Index auf die Tabelle ausgerichtet.

Warnung

Das Erstellen bzw. Neuerstellen von nicht ausgerichteten Indizes für eine Tabelle mit mehr als 1.000 Partitionen ist möglich, wird aber nicht unterstützt. Dies hätte Leistungseinbußen oder eine zu hohe Speicherauslastung während der Vorgänge zur Folge. Es wird empfohlen, nur ausgerichtete Indizes zu verwenden, wenn die Anzahl der Partitionen 1.000 überschreitet.

Beim Partitionieren eines nicht eindeutigen gruppierten Index fügt Datenbank-Engine standardmäßig alle Partitionierungsspalten zu der Liste der gruppierten Indexschlüssel hinzu, sofern sie dort noch nicht angegeben wurden.

Indizierte Sichten können für partitionierte Tabellen auf die gleiche Weise wie Indizes für Tabellen erstellt werden. Weitere Informationen zu partitionierten Indizes finden Sie in partitionierten Tabellen und Indizes sowie in der SQL Server-Indexarchitektur und im Entwurfshandbuch.

Wenn ein Index erstellt oder neu erstellt wird, optimiert die Abfrage Aktualisierungsstatistiken für den Index. Für einen partitionierten Index verwendet der Abfrageoptimierer den Standard-Samplingalgorithmus, anstatt alle Zeilen in der Tabelle auf einen nicht partitionierten Index zu scannen. Um Statistiken zu partitionierten Indizes durch das Scannen aller Zeilen in der Tabelle abzurufen, verwenden Sie CREATE STATISTICS oder UPDATE STATISTICS mit der FULLSCAN-Klausel.

Gefilterte Indizes

Ein gefilterter Index ist ein optimierter nicht gruppierter Index, der sich für Abfragen eignet, mit denen ein kleiner Prozentsatz von Zeilen in einer Tabelle ausgewählt wird. Es wird ein Filterprädikat verwendet, um einen Teil der Daten in der Tabelle zu indizieren. Ein gut entworfener gefilterter Index kann die Abfrageleistung verbessern, den Speicheraufwand verringern und Wartungskosten reduzieren.

Erforderliche SET-Optionen für gefilterte Indizes

Die SET Optionen in der Spalte "Erforderlicher Wert " sind erforderlich, wenn eine der folgenden Bedingungen auftritt:

• Sie erstellen einen gefilterten Index.

• Ein INSERT, UPDATE, , DELETEoder MERGE eine Anweisung ändert Daten in einem gefilterten Index.

• Der gefilterte Index wird vom Abfrageoptimierer verwendet, um den Abfrageplan zu erstellen.

  SET Option	Erforderlicher Wert	Standardserverwert	OLE DB- und ODBC-Standardwert	DB-Library-Standardwert
  ANSI_NULLS	ON	ON	ON	OFF
  ANSI_PADDING	ON	ON	ON	OFF
  ANSI_WARNINGS 1	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

  ¹ Einstellung ANSI_WARNINGS auf ON implizit festgelegt ARITHABORTON , wenn die Datenbankkompatibilitätsebene auf 90 oder höher festgelegt ist. Wenn die Datenbankkompatibilitätsebene auf 80 oder früher festgelegt ist, muss die ARITHABORT Option explizit auf .ON

Wenn die SET Optionen falsch sind, können die folgenden Bedingungen auftreten:

• Das Erstellen des gefilterten Indexes schlägt fehl.
• Das Datenbankmodul generiert einen Fehler und setzt die INSERTDaten UPDATEDELETEMERGE im Index zurück.
• Der Abfrageoptimierer berücksichtigt nicht den Index im Ausführungsplan für Transact-SQL-Anweisungen.

Weitere Informationen zu gefilterten Indizes finden Sie unter Erstellen gefilterter Indizes und der SQL Server-Indexarchitektur und -Entwurfsanleitung.

Räumlichkeitsindizes

Informationen zu räumlichen Indizes finden Sie unter CREATE SPATIAL INDEX and Spatial indexes overview.

XML-Indizes

Weitere Informationen zu XML-Indizes finden Sie unter CREATE XML INDEX; und XML-Indizes (SQL Server).

Indexschlüsselgröße

Die maximale Größe für einen Indexschlüssel beträgt 900 Byte für gruppierte Indizes und 1700 Byte für nicht gruppierte Indizes. (Vor SQL-Datenbank und SQL Server 2016 (13.x) war der Grenzwert immer 900 Byte.) Indizes für Varchar-Spalten , die den Bytegrenzwert überschreiten, können erstellt werden, wenn die vorhandenen Daten in den Spalten den Grenzwert zum Zeitpunkt der Erstellung des Indexes nicht überschreiten; Nachfolgende Einfüge- oder Aktualisierungsvorgänge für die Spalten, die dazu führen, dass die Gesamtgröße größer als der Grenzwert ist, schlägt jedoch fehl. Der Indexschlüssel eines gruppierten Indexes darf keine Varcharspalten enthalten, die über vorhandene Daten in der ROW_OVERFLOW_DATA Zuordnungseinheit verfügen. Wenn ein gruppierter Index in einer Varchar-Spalte erstellt wird und sich die vorhandenen Daten in der IN_ROW_DATA Zuordnungseinheit befinden, schlagen nachfolgende Einfüge- oder Aktualisierungsvorgänge für die Spalte, die die Daten außerhalb der Zeile verschiebt, fehl.

Nicht gruppierte Indizes können Nichtschlüsselspalten (eingeschlossen) in der Blattebene des Indexes enthalten. Diese Spalten werden beim Berechnen der Indexschlüsselgröße nicht vom Datenbankmodul berücksichtigt. Weitere Informationen finden Sie unter Erstellen von Indizes mit enthaltenen Spalten und der SQL Server-Indexarchitektur und -Entwurfsanleitung.

Hinweis

Falls beim Partitionieren der Tabellen die Partitionierungsschlüsselspalten nicht bereits in einem nicht eindeutigen gruppierten Index vorhanden sind, werden Sie mithilfe von Datenbank-Engine dem Index hinzugefügt. Die kombinierte Größe der indizierten Spalten (eingeschlossene Spalten werden nicht gezählt), zzgl. beliebiger hinzugefügter Partitionierungsspalten dürfen 1800 Byte in einem nicht eindeutigen gruppierten Index nicht übersteigen.

Berechnete Spalten

Indizes können für berechnete Spalten erstellt werden. Darüber hinaus können berechnete Spalten die Eigenschaft PERSISTEDaufweisen. Das bedeutet, dass Datenbank-Engine die berechneten Werte in der Tabelle speichert und sie aktualisiert, wenn andere Spalten, von denen die berechnete Spalte abhängt, aktualisiert werden. Datenbank-Engine verwendet diese persistenten Werte, wenn ein Index für die Spalte erstellt wird und wenn in einer Abfrage auf den Index verwiesen wird.

Zum Indizieren einer berechneten Spalte muss diese deterministisch und präzise sein. Die Verwendung der PERSISTED Eigenschaft erweitert jedoch den Typ der indizierbaren berechneten Spalten, um Folgendes einzuschließen:

• Auf Transact-SQL- und CLR-Funktionen basierende berechnete Spalten und Methoden des CLR-benutzerdefinierten Typs, die vom Benutzer als deterministisch markiert sind.
• Berechnete Spalten, die auf Ausdrücken basieren, die gemäß der Definition von Datenbank-Engine deterministisch, aber unpräzise sind.

Für gespeicherte berechnete Spalten müssen die folgenden SET Optionen festgelegt werden, wie im vorherigen Abschnitt "Erforderliche SET-Optionen" für gefilterte Indizes gezeigt.

Die UNIQUE Einschränkung PRIMARY KEY kann eine berechnete Spalte enthalten, solange sie alle Bedingungen für die Indizierung erfüllt. Die berechnete Spalte muss insbesondere deterministisch und präzise oder deterministisch und persistent sein. Weitere Informationen zu deterministischen Funktionen finden Sie unter Deterministische und nicht deterministische Funktionen.

Berechnete Spalten, die aus den Datentypen image, ntext, text, varchar(max) , nvarchar(max) , varbinary(max) und xml abgeleitet wurden, können entweder als Schlüssel oder eingefügte Spalte indiziert werden, bei der es sich nicht um eine Schlüsselspalte handelt, solange der Datentyp der berechneten Spalte als Indexschlüsselspalte oder Nichtschlüsselspalte zulässig ist. Sie können beispielsweise keinen primären XML-Index für eine berechnete xml-Spalte erstellen. Wenn der Indexschlüssel die zulässige Größe von 900 Byte überschreitet, wird eine Warnmeldung angezeigt.

Das Erstellen eines Indexes für eine berechnete Spalte kann dazu führen, dass ein Einfüge- oder Aktualisierungsvorgang nicht erfolgreich war. Ein solcher Fehler kann auftreten, wenn die berechnete Spalte zu einem arithmetischen Fehler führt.

Beispielsweise führt der Ausdruck der berechneten Spalte c in der folgenden Tabelle zu einem arithmetischen Fehler, wenn die Zeile eingefügt wird, die INSERT Anweisung funktioniert.

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

Wenn Sie jedoch einen Index für berechnete Spalten cerstellen, schlägt dieselbe INSERT Anweisung fehl.

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

Weitere Informationen finden Sie unter "Indizes für berechnete Spalten".

Eingeschlossene Spalten in Indizes

Nichtschlüsselspalten werden als eingeschlossene Spalten bezeichnet und können zur Blattebene eines nicht gruppierten Index hinzugefügt werden, um die Abfrageleistung durch Abdecken der Abfrage zu verbessern. Das heißt, alle Spalten, auf die in der Abfrage verwiesen wird, sind im Index als Schlüssel- oder Nichtschlüsselspalten enthalten. Auf diese Weise kann der Abfrageoptimierer alle erforderlichen Informationen aus einer nicht gruppierten Indexüberprüfung oder -suche abrufen; Auf die Tabellen- oder Gruppierten Indexdaten wird nicht zugegriffen. Weitere Informationen finden Sie unter Erstellen von Indizes mit enthaltenen Spalten und der SQL Server-Indexarchitektur und -Entwurfsanleitung.

Angeben von Indexoptionen

SQL Server 2005 (9.x) hat neue Indexoptionen eingeführt und auch die Art und Weise geändert, in der Optionen angegeben werden. In der abwärtskompatiblen Syntax WITH option_name entspricht dies WITH (option_name = ON). Beim Festlegen von Indexoptionen gelten folgende Regeln:

• Neue Indexoptionen können nur mithilfe von WITH (<option_name> = <ON | OFF>) angegeben werden.
• Optionen können nicht sowohl mithilfe der abwärtskompatiblen als auch der neuen Syntax in derselben Anweisung angegeben werden. Wenn Sie beispielsweise WITH (DROP_EXISTING, ONLINE = ON) angeben, verursacht die Anweisung einen Fehler.
• Beim Erstellen eines XML-Index müssen die Optionen mithilfe von WITH (<option_name> = <ON | OFF>) angegeben werden.

DROP_EXISTING-Klausel

Mit der DROP_EXISTING-Klausel können Sie den Index neu erstellen, Spalten hinzufügen oder löschen, Optionen ändern, die Sortierreihenfolge für Spalten ändern sowie das Partitionsschema oder die Dateigruppe ändern.

Wenn der Index eine PRIMARY KEY oder UNIQUE eine Einschränkung erzwingt und die Indexdefinition in keiner Weise geändert wird, wird der Index gelöscht und erneut erstellt, um die vorhandene Einschränkung beizubehalten. Wenn die Indexdefinition jedoch geändert wird, schlägt die Anweisung fehl. Wenn Sie die Definition einer PRIMARY KEY Oder UNIQUE Einschränkung ändern möchten, legen Sie die Einschränkung ab, und fügen Sie eine Einschränkung mit der neuen Definition hinzu.

Die DROP_EXISTING-Klausel erhöht die Leistung beim Neuerstellen eines gruppierten Index (mit der gleichen oder einer anderen Schlüsselmenge) für eine Tabelle, die auch nicht gruppierte Indizes besitzt. Die DROP_EXISTING-Klausel ersetzt die Ausführung einer DROP INDEX-Anweisung für den alten gruppierten Index mit anschließender Ausführung einer CREATE INDEX-Anweisung für den neuen gruppierten Index. Die nicht gruppierten Indizes werden einmal neu erstellt, dies aber nur dann, wenn die Indexdefinition geändert wurde. Die DROP_EXISTING-Klausel erstellt die nicht gruppierten Indizes nicht neu, wenn die Indexdefinition denselben Indexnamen, dieselben Schlüssel- und Partitionsspalten, dasselbe Eindeutigkeitsattribut und dieselbe Sortierreihenfolge wie der ursprüngliche Index aufweist.

Unabhängig davon, ob die nicht gruppierten Indizes neu erstellt werden, verbleiben sie immer in ihren ursprünglichen Dateigruppen oder Partitionsschemas und verwenden die ursprünglichen Partitionsfunktionen. Wenn ein gruppierter Index in einer anderen Dateigruppe oder einem anderen Partitionsschema neu erstellt wird, werden die nicht gruppierten Indizes nicht an den neuen Standort des gruppierten Index verschoben. Selbst wenn die nicht gruppierten Indizes, die zuvor mit dem gruppierten Index ausgerichtet wurden, nicht mehr ausgerichtet sind, werden sie möglicherweise nicht mehr daran ausgerichtet. Weitere Informationen zur Partitionierten Indexausrichtung finden Sie unter Partitionierte Tabellen und Indizes.

Die DROP_EXISTING Klausel sortiert die Daten nicht erneut, wenn die gleichen Indexschlüsselspalten in derselben Reihenfolge und mit derselben aufsteigenden oder absteigenden Reihenfolge verwendet werden, es sei denn, die Index-Anweisung gibt einen nicht gruppierten Index an, und die ONLINE Option ist auf OFFfestgelegt. Wenn der gruppierte Index deaktiviert ist, muss der CREATE INDEX WITH DROP_EXISTING Vorgang mit ONLINE "Set" OFFausgeführt werden. Wenn ein nicht gruppierter Index deaktiviert ist und keinem deaktivierten gruppierten Index zugeordnet ist, kann der CREATE INDEX WITH DROP_EXISTING Vorgang mit ONLINE "Set" OFF oder ON".

Hinweis

Wenn Indizes mit 128 oder mehr Blöcken gelöscht oder neu erstellt werden, verzögert Datenbank-Engine die eigentlichen Seitenzuordnungsaufhebungen und die zugehörigen Sperren bis zu einem Zeitpunkt nach dem Transaktionscommit. Weitere Informationen finden Sie unter deferred deallocation.

ONLINE (Option)

Die folgenden Regeln gelten für das Durchführen von Onlineindexvorgängen:

• Die zugrunde liegende Tabelle kann nicht geändert, abgeschnitten oder gelöscht werden, während ein Onlineindexvorgang verarbeitet wird.
• Beim Indexvorgang ist zusätzlicher temporärer Speicherplatz erforderlich.
• Onlinevorgänge können für partitionierte Indizes und Indizes durchgeführt werden, die persistente berechnete Spalten oder eingeschlossene Spalten enthalten.
• Mit der WAIT_AT_LOW_PRIORITY Argumentoption können Sie entscheiden, wie der Indexvorgang fortgesetzt wird, wenn er auf eine Sch-M Sperre wartet. Weitere Informationen finden Sie unter WAIT_AT_LOW_PRIORITY

Weitere Informationen finden Sie unter Ausführen von Indexvorgängen online.

Fortsetzbare Indexvorgänge

gilt für: SQL Server 2019 (15.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

Sie können einen Onlineindex-Erstellungsvorgang reaktivieren. Dies bedeutet, dass der Indexbuild angehalten und später neu gestartet werden kann, von dem Punkt, an dem er angehalten wurde. Wenn Sie einen Indexbuild als fortsetzungsfähig ausführen möchten, geben Sie die RESUMABLE = ON Option an.

Die folgenden Richtlinien gelten für reaktivierbare Indexvorgänge:

• Um die option RESUMABLE zu verwenden, müssen Sie auch die Option ONLINE verwenden.
• Die option RESUMABLE wird in den Metadaten für einen bestimmten Index nicht beibehalten und gilt nur für die Dauer der aktuellen DDL-Anweisung. Daher muss die RESUMABLE = ON-Klausel explizit angegeben werden, wenn Fortsetzbarkeit aktiviert werden soll.
• Die option MAX_DURATION kann in zwei Kontexten angegeben werden:
  • MAX_DURATION für die RESUMABLE Option gibt das Zeitintervall für einen Neuaufbau eines Indexes an. Nach ablauf dieser Zeit und wenn die Indexerstellung noch ausgeführt wird, wird sie angehalten. Sie entscheiden, wann die Neuerstellung für einen angehaltenen Index fortgesetzt werden kann. Die Zeit in Minuten für MAX_DURATION muss größer als 0 Minuten und kleiner oder gleich einer Woche sein (7 * 24 * 60 = 10080 Minuten). Eine lange Pause in einem Indexvorgang wirkt sich möglicherweise spürbar auf die DML-Leistung einer bestimmten Tabelle sowie die Kapazität des Datenbankdatenträgers aus, da sowohl der ursprüngliche Index als auch der neu erstellte Index Speicherplatz erfordern und von DML-Vorgängen aktualisiert werden müssen. Wenn MAX_DURATION Option nicht angegeben wird, wird der Indexvorgang bis zum Abschluss oder bis zum Auftreten eines Fehlers fortgesetzt.
  • MAX_DURATION für die Option WAIT_AT_LOW_PRIORITY gibt die Wartezeit mit Sperren mit niedriger Priorität an, wenn der Indexvorgang blockiert wird, bevor Eine Aktion ausgeführt wird. Weitere Informationen finden Sie unter WAIT_AT_LOW_PRIORITY mit Onlineindexvorgängen.
• Um den Indexvorgang sofort anzuhalten, können Sie den befehl ALTER INDEX PAUSE ausführen oder den befehl KILL <session_id> ausführen.
• Durch erneutes Ausführen der ursprünglichen CREATE INDEX Anweisung mit denselben Parametern wird ein angehaltener Indexbuildvorgang fortgesetzt. Sie können auch einen angehaltenen Indexbuildvorgang fortsetzen, indem Sie die ALTER INDEX RESUME Anweisung ausführen.
• Der Befehl ABORT beendet die Sitzung, in der ein Indexbuild ausgeführt wird, und bricht den Indexvorgang ab. Sie können keinen Indexvorgang fortsetzen, der abgebrochen wurde.

Ein reaktivierbarer Indexvorgang wird ausgeführt, bis er abgeschlossen, angehalten oder fehlschlägt. Falls der Vorgang angehalten wird, wird ein Fehler ausgegeben, der angibt, dass der Vorgang angehalten wurde und dass die Indexerstellung nicht abgeschlossen wurde. Falls der Vorgang fehlschlägt, wird auch ein Fehler ausgegeben.

Um festzustellen, ob ein Indexvorgang als reaktivierbarer Vorgang ausgeführt wird und um den aktuellen Ausführungsstatus zu überprüfen, verwenden Sie die sys.index_resumable_operations Katalogansicht.

Ressourcen

Die folgenden Ressourcen sind für reaktivierbare Indexvorgänge erforderlich:

• Zusätzlicher Speicherplatz, der erforderlich ist, um den zu erstellenden Index beizubehalten, einschließlich der Zeit, zu der der Build angehalten wird.
• Zusätzlicher Protokolldurchsatz während der Sortierungsphase Der insgesamt durch Protokolle belegte Speicherplatz für den fortsetzbaren Index ist geringer als bei der Erstellung eines regulären Onlineindexes. Zudem ist eine Protokollkürzung während dieses Vorgangs möglich.
• DDL-Anweisungen, die versuchen, die dem zu erstellenden Index zugeordnete Tabelle zu ändern, während der Indexvorgang angehalten wird, sind nicht zulässig.
• Ein Cleanup inaktiver Datensätze wird für den Index innerhalb des Builds für die Dauer des Vorgangs blockiert, während dieser angehalten und auch während der Vorgang ausgeführt wird.
• Wenn die Tabelle BRANCHENspalten enthält, erfordert ein resumierbarer Clusterindexbuild eine Schemaänderung (Sch-M) am Anfang des Vorgangs.

Aktuelle funktionale Einschränkungen

Reaktivierbare Indexerstellungsvorgänge weisen die folgenden Einschränkungen auf:

• Nachdem ein reaktivierbarer Onlineindexerstellungsvorgang angehalten wurde, kann der Anfangswert nicht MAXDOP mehr geändert werden.
• Die Option SORT_IN_TEMPDB = ON wird für reaktivierbare Indexvorgänge nicht unterstützt.
• Der DDL-Befehl mit RESUMABLE = ON kann nicht innerhalb einer expliziten Transaktion ausgeführt werden.
• Sie können keinen reaktivierbaren Index erstellen, der Folgendes enthält:
  • Berechnete oder timestamp (rowversion) Spalten als Schlüsselspalten.
  • Lob-Spalte als eingeschlossene Spalte.
• Reaktivierbare Indexvorgänge werden nicht unterstützt für:
  • Der Befehl ALTER INDEX REBUILD ALL
  • Der Befehl ALTER TABLE REBUILD
  • Columnstore-Indizes
  • Gefilterte Indizes
  • Deaktivierte Indizes

WAIT_AT_LOW_PRIORITY bei Onlineindexvorgängen

gilt für: SQL Server 2022 (16.x) und höhere Versionen, Azure SQL-Datenbank und azure SQL Managed Instance

Wenn Sie die WAIT_AT_LOW_PRIORITY Option nicht verwenden, müssen alle aktiven blockierenden Transaktionen, die Sperren in der Tabelle oder im Index enthalten, abgeschlossen sein, damit der Indexerstellungsvorgang gestartet und abgeschlossen werden kann. Wenn der Onlineindexvorgang gestartet wird und bevor er abgeschlossen wird, muss er eine freigegebene (S) oder eine Schemaänderung (Sch-M) auf der Tabelle erwerben und diese für kurze Zeit halten. Auch wenn die Sperre nur für kurze Zeit gehalten wird, kann sie sich erheblich auf den Workloaddurchsatz auswirken, die Abfragelatenz erhöhen oder Ausführungstimeouts verursachen.

Um diese Probleme zu vermeiden, können Sie mit der Option WAIT_AT_LOW_PRIORITY das Verhalten von S oder Sch-M Sperren verwalten, die für den Start und Abschluss eines Onlineindexvorgangs erforderlich sind, und wählen Sie aus drei Optionen aus. Wenn während der durch MAX_DURATION = n [minutes] angegebenen Wartezeit in allen Fällen keine Blockierung vorhanden ist, die den Indexvorgang umfasst, wird der Indexvorgang sofort fortgesetzt.

WAIT_AT_LOW_PRIORITY den Onlineindexvorgang mit Sperren mit niedriger Priorität warten lässt, sodass andere Vorgänge mit normalen Prioritätssperren in der Zwischenzeit fortgesetzt werden können. Das Weglassen der WAIT_AT_LOW_PRIORITY-Option ist gleichwertig mit WAIT_AT_LOW_PRIORITY (MAX_DURATION = 0 minutes, ABORT_AFTER_WAIT = NONE).

MAX_DURATION = Zeit [MINUTES]

Die Wartezeit (ein ganzzahliger Wert, der in Minuten angegeben ist), die der Onlineindexvorgang mit Sperren mit niedriger Priorität wartet. Wenn der Vorgang für die MAX_DURATION Zeit blockiert wird, wird die angegebene ABORT_AFTER_WAIT Aktion ausgeführt. MAX_DURATION Die Zeit ist immer in Minuten, und das Wort MINUTES kann weggelassen werden.

ABORT_AFTER_WAIT = [NONE | SELF | BLOCKERS ]

• NONE: Warten Sie weiterhin auf die Sperre mit normaler Priorität.
• SELF: Beenden Sie den derzeit ausgeführten Onlineindexvorgang, ohne eine Aktion auszuführen. Die Option SELF kann nicht verwendet werden, wenn MAX_DURATION 0 ist.
• BLOCKERS: Beenden Sie alle Benutzertransaktionen, die den Onlineindexvorgang blockieren, damit der Vorgang fortgesetzt werden kann. Für die option BLOCKERS muss der Prinzipal die CREATE INDEX- oder ALTER INDEX-Anweisung ausführen, um über die ALTER ANY CONNECTION-Berechtigung zu verfügen.

Sie können die folgenden erweiterten Ereignisse verwenden, um Indexvorgänge zu überwachen, die auf Sperren mit niedriger Priorität warten:

• lock_request_priority_state
• process_killed_by_abort_blockers
• ddl_with_wait_at_low_priority

Zeilen- und Seitensperren (Optionen)

Wenn ALLOW_ROW_LOCKS = ON und ALLOW_PAGE_LOCK = ON angegeben sind, sind Sperren auf Zeilen-, Seiten- und Tabellenebene zulässig, wenn auf den Index zugegriffen wird. Das Datenbank-Engine wählt die geeignete Sperre aus und kann die Sperre von einer Zeilen- oder Seitensperre auf eine Tabellensperre ausweiten.

Wenn ALLOW_ROW_LOCKS = OFF und ALLOW_PAGE_LOCK = OFF angegeben sind, ist nur eine Sperre auf Tabellenebene zulässig, wenn auf den Index zugegriffen wird.

Warnung

Es wird nicht empfohlen, Zeilen- oder Seitensperren für einen Index zu deaktivieren. Parallelitätsprobleme können auftreten, und bestimmte Funktionen sind möglicherweise nicht verfügbar. Beispielsweise kann ein Index nicht neu organisiert werden, wenn ALLOW_PAGE_LOCKS auf OFFfestgelegt ist.

Sequenzielle Schlüssel

Gilt für: SQL Server 2019 (15.x) und höhere Versionen, in Azure SQL-Datenbank und in azure SQL Managed Instance.

Das Leistungsproblem von Speicherkonflikten bei Einfügevorgängen für die letzte Seite tritt häufig auf, wenn eine große Anzahl von gleichzeitigen Threads versucht, Zeilen in einen Index mit einem sequentiellen Schlüssel einzufügen. Ein Index wird als sequentiell betrachtet, wenn die führende Schlüsselspalte Werte enthält, die immer größer (oder kleiner) werden, wie beispielsweise eine Identitätsspalte oder ein Datum, das auf das aktuelle Datum/Uhrzeit voreingestellt ist. Da die eingefügten Schlüssel sequenziell sind, werden alle neuen Zeilen am Ende der Indexstruktur eingefügt , d. h. auf derselben Seite. Dies führt zu einem Streit für die Seite im Speicher, die als mehrere Threads beobachtet werden kann, die darauf warten, eine Sperre für die betreffende Seite zu erhalten. Der entsprechende Wartetyp lautet PAGELATCH_EX.

Durch Aktivieren der Indexoption OPTIMIZE_FOR_SEQUENTIAL_KEY wird eine Optimierung in der Datenbank-Engine aktiviert, die den Durchsatz für Einfügevorgänge mit hoher Parallelität in den Index verbessert. Dies ist für Indizes vorgesehen, die einen sequenziellen Schlüssel enthalten und bei denen es daher verstärkt zu Speicherkonflikten bei Einfügevorgängen für die letzte Seite kommen kann, kann aber auch für Indizes verwendet werden, die Hotspots in anderen Bereichen des B-Strukturindex aufweisen.

Hinweis

In der Dokumentation wird der Begriff „B-Struktur“ im Allgemeinen in Bezug auf Indizes verwendet. In Zeilenspeicherindizes implementiert die Datenbank-Engine eine B+-Struktur. Dies gilt nicht für Columnstore-Indizes oder In-Memory-Datenspeicher. Weitere Informationen finden Sie im Leitfaden zur Architektur und zum Entwerfen von SQL Server- und Azure SQL-Indizes.

Datenkomprimierung

Weitere Informationen zur Datenkomprimierung finden Sie unter "Datenkomprimierung".

Nachfolgend sind die wichtigsten Punkte aufgeführt, die im Kontext von Indexbuildvorgängen beim Verwenden der Datenkomprimierung berücksichtigt werden sollten:

• Die Komprimierung kann es ermöglichen, mehr Zeilen auf einer Seite zu speichern, die maximale Zeilengröße wird dadurch allerdings nicht geändert.
• Nicht-Blattseiten eines Index sind nicht seitenkomprimiert, können jedoch zeilenkomprimiert sein.
• Jeder nicht gruppierte Index verfügt über eine eigene Komprimierungseinstellung und erbt die Komprimierungseinstellung nicht von der zugrunde liegenden Tabelle.
• Wenn ein gruppierter Index auf einem Heap erstellt wird, erbt der gruppierte Index den Komprimierungsstatus des Heaps, sofern kein anderer Komprimierungsstatus angegeben wird.

Um zu bewerten, wie sich das Ändern des Komprimierungszustands auf die Speicherplatznutzung durch eine Tabelle, einen Index oder eine Partition auswirkt, verwenden Sie die sp_estimate_data_compression_savings gespeicherten Prozedur.

XML-Komprimierung

Gilt für: SQL Server 2022 (16.x) und höher, Azure SQL-Datenbank, Azure SQL Managed Instance

Viele der Überlegungen zur Datenkomprimierung gelten für die XML-Komprimierung. Beachten Sie auch die folgenden Aspekte:

• Bei Angabe einer Liste mit Partitionen kann die XML-Komprimierung für einzelne Partitionen aktiviert werden. Wenn die Liste der Partitionen nicht angegeben ist, wird für alle Partitionen die Verwendung der XML-Komprimierung festgelegt. Bei Erstellung einer Tabelle oder eines Indexes wird die XML-Datenkomprimierung deaktiviert, falls nicht anders angegeben. Bei Änderung einer Tabelle wird die vorhandene Komprimierung beibehalten, falls nicht anders angegeben.
• Wenn Sie eine Partitionsliste bzw. eine Partition außerhalb des zulässigen Bereichs angeben, wird ein Fehler generiert.
• Wenn ein gruppierter Index auf einem Heap erstellt wird, erbt der gruppierte Index den XML-Komprimierungsstatus des Heaps, sofern keine andere Komprimierungsoption angegeben wird.
• Zur Änderung der XML-Komprimierungseinstellung für einen Heap müssen alle nicht gruppierten Indizes der Tabelle neu erstellt werden, sodass sie auf die neuen Zeilenpositionen im Heap zeigen.
• Sie können die XML-Komprimierung online oder offline aktivieren und deaktivieren. Die Online-Aktivierung der Komprimierung für einen Heap erfolgt mit einem einzelnen Thread.
• Verwenden Sie die xml_compression Spalte der sys.partitions Katalogansicht, um den XML-Komprimierungsstatus von Partitionen in einer partitionierten Tabelle zu ermitteln.

Indexstatistik

Wenn ein Rowstore-Index erstellt wird, erstellt das Datenbankmodul auch Statistiken zu den Schlüsselspalten des Indexes. Der Name des Statistikobjekts in der Sys.stats-Katalogansicht entspricht dem Namen des Indexes. Bei einem nicht partitionierten Index werden die Statistiken mithilfe einer vollständigen Überprüfung der Daten erstellt. Für einen partitionierten Index werden Statistiken mit dem Standardsamplingalgorithmus erstellt.

Wenn ein Columnstore-Index erstellt wird, erstellt das Datenbankmodul auch ein Statistikobjekt in sys.stats . Dieses Statistikobjekt enthält keine Statistikdaten wie das Histogramm und den Dichtevektor. Sie wird beim Erstellen eines Datenbankklons durch Skripting der Datenbank verwendet. Zu diesem Zeitpunkt werden die DBCC SHOW_STATISTICS Befehle und UPDATE STATISTICS ... WITH STATS_STREAM Befehle zum Abrufen von Spaltenspeichermetadaten wie Segment, Wörterbuch und Deltaspeichergröße verwendet und der Statistik für den Columnstore-Index hinzugefügt. Diese Metadaten werden dynamisch zur Abfragekompilierungszeit für eine normale Datenbank abgerufen, aber vom Statistikobjekt für einen Datenbankklon bereitgestellt. Der Befehl UPDATE STATISTICS wird für das Statistikobjekt in einem Columnstore-Index in einem anderen Szenario nicht unterstützt.

Berechtigungen

Erfordert die ALTER Berechtigung für die Tabelle oder Ansicht oder Mitgliedschaft in der db_ddladmin festen Datenbankrolle.

Einschränkungen

In Azure Synapse Analytics und Analytics Platform System (PDW) können Sie Folgendes nicht erstellen:

• Einen gruppierten oder nicht gruppierten Rowstore-Index für eine Data Warehouse-Tabelle, wenn ein Columnstore-Index bereits vorhanden ist. Dieses Verhalten unterscheidet sich von SMP SQL Server, da dieser Dienst es zulässt, dass Rowstore- und Columnstore-Indizes beide in derselben vorhanden sind.
• Sie können keinen Index für eine Sicht erstellen.

Metadaten

Informationen zu vorhandenen Indizes erhalten Sie, wenn Sie die sys.indexes-Katalogsicht abfragen.

Versionshinweise

• Azure SQL-Datenbank unterstützt keine anderen Dateigruppen als PRIMARY.
• Azure SQL-Datenbank und azure SQL Managed Instance unterstützen keine FILESTREAM Optionen.
• Columnstore-Indizes sind vor SQL Server 2012 (11.x) nicht verfügbar.
• Resumable Index-Vorgänge sind ab SQL Server 2017 (14.x), in Azure SQL-Datenbank und in azure SQL Managed Instance verfügbar.

Beispiele: Alle Versionen. Verwendet die AdventureWorks-Datenbank.

A. Erstellen eines einfachen nicht gruppierten Rowstore-Index

Im folgenden Beispiel wird ein nicht gruppierter Index für die Spalte VendorID der Tabelle Purchasing.ProductVendor erstellt.

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. Erstellen eines einfachen nicht gruppierten zusammengesetzten Rowstore-Index

Im folgenden Beispiel wird ein nicht gruppierter zusammengesetzter Index für die Spalten SalesQuota und SalesYTD der Tabelle Sales.SalesPerson erstellt.

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

C. Erstellen eines Index für eine Tabelle in einer anderen Datenbank

Im folgenden Beispiel wird ein gruppierter Index für die VendorID-Spalte der ProductVendor-Tabelle in der Purchasing-Datenbank erstellt.

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

D: Hinzufügen einer Spalte zu einem Index

Im folgenden Beispiel wird der Index X_FF mit zwei Spalten der dbo.FactFinance-Tabelle erstellt. Die nächste Anweisung erstellt den Index mit zwei weiteren Spalten neu und behält den bereits vorhandenen Namen bei.

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

Beispiele: SQL Server, Azure SQL-Datenbank

E. Erstellen eines eindeutigen nicht gruppierten Index

Im folgenden Beispiel wird ein eindeutiger nicht gruppierter Index für die Name-Spalte der Production.UnitMeasure-Tabelle in der AdventureWorks2022-Datenbank erstellt. Der Index erzwingt Eindeutigkeit für die Daten, die in die Spalte Name eingefügt werden.

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

In der folgenden Abfrage wird die Eindeutigkeitseinschränkung getestet, indem eine Zeile mit demselben Wert wie in einer vorhandenen Zeile eingefügt wird.

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

Die folgende Fehlermeldung wird angezeigt:

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. Verwenden der IGNORE_DUP_KEY-Option

Das folgende Beispiel veranschaulicht die Wirkung der Option IGNORE_DUP_KEY, indem mehrere Zeilen zunächst mit dem Optionswert ON und anschließend mit dem Optionswert OFF in eine temporäre Tabelle eingefügt werden. Eine einzelne Zeile wird in die #Test-Tabelle eingefügt, die absichtlich einen doppelten Wert erzeugt, wenn die zweite mehrzeilige INSERT-Anweisung ausgeführt wird. Eine Zählung der Zeilen in der Tabelle gibt die Anzahl der eingefügten Zeilen zurück.

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

Im Folgenden werden die Ergebnisse der zweiten INSERT-Anweisung aufgeführt.

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

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

Beachten Sie, dass die aus der Tabelle Production.UnitMeasure eingefügten Zeilen, die die Eindeutigkeitseinschränkung nicht verletzten, erfolgreich eingefügt wurden. Es wurde eine Warnung ausgegeben, und die doppelte Zeile wurde ignoriert, aber es wurde kein Rollback für die gesamte Transaktion ausgeführt.

Dieselben Anweisungen werden erneut ausgeführt. Dabei ist die Option IGNORE_DUP_KEY allerdings auf OFF festgelegt.

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

Im Folgenden werden die Ergebnisse der zweiten INSERT-Anweisung aufgeführt.

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

Beachten Sie, dass keine Zeilen aus der Production.UnitMeasure-Tabelle in die Tabelle eingefügt wurden, obwohl nur eine Zeile in der Tabelle die UNIQUE-Einschränkung für den Index verletzte.

G. Verwenden von DROP_EXISTING zum Löschen und Neuerstellen eines Index

Im folgenden Beispiel wird ein vorhandener Index für die ProductID-Spalte der Production.WorkOrder-Tabelle in der AdventureWorks2022-Datenbank mithilfe der DROP_EXISTING-Option gelöscht und neu erstellt. Die Optionen FILLFACTOR und PAD_INDEX sind ebenfalls festgelegt.

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

H. Erstellen eines Index für eine Sicht

Im folgenden Beispiel werden eine Sicht und ein Index für diese Sicht erstellt. Dies beinhaltet zwei Abfragen, in denen die indizierte Sicht verwendet wird.

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

I. Erstellen eines Index mit eingeschlossenen (Nichtschlüssel-)Spalten

Im folgenden Beispiel wird ein nicht gruppierter Index mit einer Schlüsselspalte (PostalCode) und vier Nichtschlüsselspalten (AddressLine1, AddressLine2, City, StateProvinceID) erstellt. Es folgt eine Abfrage, die vom Index abgedeckt wird. Wenn Sie den vom Abfrageoptimierer ausgewählten Index anzeigen möchten, wählen Sie in SQL Server Management Studio im Menü Abfrage die Option Display Actual Execution Plan (Tatsächlichen Ausführungsplan einschließen) aus.

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. Erstellen eines partitionierten Index

Im folgenden Beispiel wird ein nicht gruppierter partitionierter Index für TransactionsPS1 (ein vorhandenes Partitionsschema in der AdventureWorks2022-Datenbank) erstellt. Dieses Beispiel setzt voraus, dass das Beispiel für einen partitionierten Index installiert wurde.

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

K. Erstellen eines gefilterten Index

Im folgenden Beispiel wird ein gefilterter Index für die Production.BillOfMaterialsAdventureWorks2022-Tabelle in der -Datenbank erstellt. Das Filterprädikat kann Spalten einschließen, die keine Schlüsselspalten im gefilterten Index sind. Das Prädikat in diesem Beispiel wählt nur die Zeilen aus, in denen EndDate nicht NULL ist.

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

L. Erstellen eines komprimierten Index

Im folgenden Beispiel wird ein Index für eine nicht partitionierte Tabelle unter Verwendung der Zeilenkomprimierung erstellt.

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

Im folgenden Beispiel wird ein Index für eine partitionierte Tabelle unter Verwendung der Zeilenkomprimierung für alle Partitionen des Indexes erstellt.

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

Im folgenden Beispiel wird ein Index für eine partitionierte Tabelle erstellt, wobei die Seitenkomprimierung für Partition 1 des Indexes und die Zeilenkomprimierung für die Partitionen 2 bis 4 des Indexes verwendet wird.

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. Erstellen eines Indexes mit XML-Komprimierung

Gilt für: SQL Server 2022 (16.x) und höher, Azure SQL-Datenbank, Azure SQL Managed Instance

Im folgenden Beispiel wird ein Index für eine nicht partitionierte Tabelle unter Verwendung der XML-Komprimierung erstellt. Mindestens eine Spalte im Index muss den XML-Datentyp aufweisen.

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

Im folgenden Beispiel wird ein Index für eine partitionierte Tabelle unter Verwendung der XML-Komprimierung für alle Partitionen des Indexes erstellt.

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

N. Erstellen, Fortsetzen, Anhalten und Abbrechen von Vorgängen fortsetzbarer Indizes

gilt für: SQL Server 2019 (15.x) und höhere Versionen, Azure SQL-Datenbank und 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. CREATE INDEX mit anderen Sperrzeitoptionen mit niedriger Priorität

In den folgenden Beispielen wird die WAIT_AT_LOW_PRIORITY-Option verwendet, um verschiedene Strategien für den Umgang mit Blockierungen anzugeben.

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

Im folgenden Beispiel wird die RESUMABLE-Option verwendet und es werden zwei MAX_DURATION-Werte angegeben, wobei der erste für die ABORT_AFTER_WAIT-Option und der zweite für die RESUMABLE-Option gilt.

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

Beispiele: Azure Synapse Analytics und Analytics-Plattformsystem (PDW)

P. Grundlegende Syntax

Erstellen, Fortsetzen, Anhalten und Abbrechen von Vorgängen fortsetzbarer Indizes

gilt für: SQL Server 2019 (15.x) und höhere Versionen, Azure SQL-Datenbank und 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. Erstellen eines nicht gruppierten Index für eine Tabelle in der aktuellen Datenbank

Im folgenden Beispiel wird ein nicht gruppierter Index für die Spalte VendorID der Tabelle ProductVendor erstellt.

CREATE INDEX IX_ProductVendor_VendorID
  ON ProductVendor (VendorID);

R. Erstellen eines nicht gruppierten Index für eine Tabelle in einer anderen Datenbank

Im folgenden Beispiel wird ein nicht gruppierter Index für die VendorID-Spalte der ProductVendor-Tabelle in der Purchasing-Datenbank erstellt.

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

S. Erstellen eines geordneten gruppierten Index für eine Tabelle

Im folgenden Beispiel wird ein geordneter gruppierter Index für die c1-Spalte und die c2-Spalte der T1-Tabelle in der MyDB-Datenbank erstellt.

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

T. Umwandeln eines gruppierten Columnstore-Index in einen geordneten gruppierten Index für eine Tabelle

Im folgenden Beispiel wird der vorhandene gruppierte Columnstore-Index in einen geordneten gruppierten Columnstore-Index mit dem Namen MyOrderedCCI für die Spalten c1 und c2 der Tabelle T2 in der Datenbank MyDB umgewandelt.

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

Verwandte Inhalte

• Leitfaden zur Architektur und zum Entwurf von SQL Server-Indizes
• Ausführen von Onlineindexvorgängen
• Indizes und ALTER TABLE
• ALTER INDEX
• CREATE PARTITION FUNCTION
• CREATE PARTITION SCHEME
• CREATE SPATIAL INDEX
• CREATE STATISTICS
• CREATE TABLE
• CREATE XML INDEX
• Datentypen
• DBCC SHOW_STATISTICS
• DROP INDEX
• XML-Indizes (SQL Server)
• sys.indexes
• sys.index_columns
• sys.xml_indexes
• EVENTDATA