Freigeben über

Tabellenhinweise (Transact-SQL)

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance SQL-Datenbank in Microsoft Fabric

Tabellenhinweise werden dazu genutzt, das Standardverhalten des Abfrageoptimierers während der Dauer einer DML-Anweisung (Data Manipulation Language) außer Kraft zu setzen. Sie können eine Sperrmethode, einen oder mehrere Indizes, einen Vorgang zur Abfrageverarbeitung wie z. B. einen Tabellenscan, eine Indexsuche oder andere Optionen angeben. Tabellenhinweise werden in der FROM-Klausel der DML-Anweisung angegeben und wirken sich nur auf die Tabelle oder Sicht aus, auf die in der betreffenden Klausel verwiesen wird.

Achtung

Da der SQL Server-Abfrageoptimierer in der Regel den optimalen Ausführungsplan für eine Abfrage auswählt, wird empfohlen, dass erfahrene Entwickler und Datenbankadministratoren Hinweise nur dann verwenden, wenn alle anderen Möglichkeiten sich als unzureichend erwiesen haben.

Anwendungsbereich:

Transact-SQL-Syntaxkonventionen

Syntax

WITH  ( <table_hint> [ [ , ] ...n ] )

<table_hint> ::=
{ NOEXPAND
  | INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> )
  | FORCESEEK [ ( <index_value> ( <index_column_name> [ , ... ] ) ) ]
  | FORCESCAN
  | HOLDLOCK
  | NOLOCK
  | NOWAIT
  | PAGLOCK
  | READCOMMITTED
  | READCOMMITTEDLOCK
  | READPAST
  | READUNCOMMITTED
  | REPEATABLEREAD
  | ROWLOCK
  | SERIALIZABLE
  | SNAPSHOT
  | SPATIAL_WINDOW_MAX_CELLS = <integer_value>
  | TABLOCK
  | TABLOCKX
  | UPDLOCK
  | XLOCK
}

<table_hint_limited> ::=
{
    KEEPIDENTITY
  | KEEPDEFAULTS
  | HOLDLOCK
  | IGNORE_CONSTRAINTS
  | IGNORE_TRIGGERS
  | NOLOCK
  | NOWAIT
  | PAGLOCK
  | READCOMMITTED
  | READCOMMITTEDLOCK
  | READPAST
  | REPEATABLEREAD
  | ROWLOCK
  | SERIALIZABLE
  | SNAPSHOT
  | TABLOCK
  | TABLOCKX
  | UPDLOCK
  | XLOCK
}

Argumente

WITH ( <Tabellenhinweis> ) [ [ , ] ...n ]

Bis auf einige Ausnahmen werden Tabellenhinweise nur dann in der FROM-Klausel unterstützt, wenn die Hinweise mit dem WITH-Schlüsselwort angegeben werden. Tabellenhinweise müssen zudem mit Klammern angegeben werden.

Wichtig

Das Weglassen des WITH-Schlüsselworts ist ein veraltetes Feature: Dieses Feature wird in einer zukünftigen Version von SQL Server entfernt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden.

Die folgenden Tabellenhinweise sind mit dem und ohne das Schlüsselwort WITH zulässig: NOLOCK, READUNCOMMITTED, UPDLOCK, REPEATABLEREAD, SERIALIZABLE, READCOMMITTED, TABLOCK, TABLOCKX, PAGLOCK, ROWLOCK, NOWAIT, READPAST, XLOCK, SNAPSHOT und NOEXPAND. Wenn bei diesen Tabellenhinweisen nicht das WITH-Schlüsselwort festgelegt wird, sollten sie separat angegeben werden. Beispiel:

FROM t (TABLOCK)

Wenn der Hinweis mit einer anderen Option angegeben wird, muss er mit dem WITH-Schlüsselwort angegeben werden:

FROM t WITH (TABLOCK, INDEX(myindex))

Es wird empfohlen, Tabellenhinweise durch Kommas voneinander zu trennen.

Wichtig

Das Trennen von Hinweisen durch Leerzeichen anstelle von Kommas ist ein veraltetes Feature: Dieses Feature wird in einer zukünftigen Version von SQL Server entfernt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden.

NOEXPAND

Gibt an, dass indizierte Sichten nicht für den Zugriff auf zugrunde liegende Tabellen erweitert werden, wenn der Abfrageoptimierer die Abfrage verarbeitet. Der Abfrageoptimierer behandelt die Sicht wie eine Tabelle mit einem gruppierten Index. NOEXPAND gilt nur für indizierte Sichten. Weitere Informationen finden Sie unter Verwenden von NOEXPAND.

INDEX ( <Indexwert> [ , ...n ] ) | INDEX = ( <Indexwert> )

Mit der INDEX()-Syntax werden die Namen oder IDs der Indizes angegeben, die der Abfrageoptimierer beim Verarbeiten der Anweisung verwenden soll. Die alternative Syntax INDEX = gibt einen einzigen Indexwert an. Pro Tabelle ist nur ein Indexhinweis zulässig.

Falls ein gruppierter Index vorhanden ist, erzwingt INDEX(0) eine Überprüfung des gruppierten Index, und INDEX(1) erzwingt eine Überprüfung des gruppierten Index oder eine Suche im gruppierten Index. Falls kein gruppierter Index vorhanden ist, erzwingt INDEX(0) einen Tabellenscan, und INDEX(1) wird als Fehler interpretiert.

Bei Verwendung mehrerer Indizes in einer einzigen Hinweisliste werden Duplikate ignoriert, und die übrigen aufgeführten Indizes werden zum Abrufen der Zeilen aus der Tabelle verwendet. Die Reihenfolge der Indizes im Indexhinweis ist von Bedeutung. Mehrere Indexhinweise erzwingen die AND-Verknüpfung der Indizes, und der Abfrageoptimierer versucht, so viele Bedingungen wie möglich auf jeden verwendeten Index anzuwenden. Falls die Auflistung der Indexhinweise nicht alle in der Abfrage referenzierten Spalten umfasst, wird ein Abrufvorgang ausgeführt, um die restlichen Spalten abzurufen, nachdem die SQL Server-Datenbank-Engine alle indizierten Spalten abgerufen hat.

Hinweis

Wenn ein Indexhinweis, der auf mehrere Indizes verweist, in der Faktentabelle eines Sternjoins verwendet wird, ignoriert der Optimierer den Indexhinweis und gibt eine Warnmeldung zurück. Außerdem ist die OR-verknüpfte Indexsuche für Tabellen mit einem Indexhinweis nicht zulässig.

Die maximale Anzahl nicht gruppierter Indizes im Tabellenhinweis beträgt 250.

KEEPIDENTITY

Gilt nur in einer INSERT-Anweisung, wenn die BULK-Option mit OPENROWSET verwendet wird.

Gibt an, dass der oder die Identitätswerte in der importierten Datendatei für die Identitätsspalte verwendet werden sollen. Wird KEEPIDENTITY nicht angegeben, werden die Identitätswerte für diese Spalte zwar überprüft, nicht jedoch importiert, und der Abfrageoptimierer weist auf der Grundlage von Ausgangswerten und den inkrementellen Werten, die beim Erstellen der Tabelle angegeben wurden, eindeutige Werte zu.

Wichtig

Wenn die Datendatei keine Werte für die Identitätsspalte in der Tabelle oder Sicht enthält und die Identitätsspalte nicht die letzte Spalte der Tabelle ist, müssen Sie die Identitätsspalte überspringen. Weitere Informationen finden Sie unter Auslassen eines Datenfelds mithilfe einer Formatdatei (SQL Server). Wenn eine Identitätsspalte erfolgreich übersprungen wird, weist der Abfrageoptimierer der Identitätsspalte in den importierten Tabellenzeilen automatisch eindeutige Werte zu.

Ein Beispiel, in dem dieser Hinweis in einer INSERT ... SELECT * FROM OPENROWSET(BULK...)-Anweisung verwendet wird, finden Sie unter Beibehalten von Identitätswerten beim Massenimport von Daten (SQL Server).

Weitere Informationen zum Überprüfen des Identitätswerts für eine Tabelle finden Sie unter DBCC CHECKIDENT (Transact-SQL).

KEEPDEFAULTS

Gilt nur in einer INSERT-Anweisung, wenn die BULK-Option mit OPENROWSET verwendet wird.

Gibt an, dass statt NULL der Standardwert einer Tabellenspalte (falls vorhanden) einzufügen ist, wenn der Datensatz keinen Wert für die Spalte aufweist.

Ein Beispiel für die Verwendung dieses Hinweises in einer INSERT ... SELECT * FROM OPENROWSET(BULK...)-Anweisung finden Sie unter Beibehalten von NULL-Werten oder Verwenden von Standardwerten während des Massenimports (SQL Server).

FORCESEEK [ ( <Indexwert> ( <Name_der_Indexspalte> [ , ...n ] ) ) ]

Gibt an, dass der Abfrageoptimierer nur einen Indexsuchvorgang als Zugriffspfad für die in der Tabelle oder Sicht angegebenen Daten verwenden darf.

Hinweis

Ab SQL Server 2008 R2 (10.50.x) Service Pack 1 können auch Indexparameter angegeben werden. Der Abfrageoptimierer berücksichtigt in diesem Fall nur Indexsuchvorgänge über den angegebenen Index mit mindestens den angegebenen Indexspalten.

  • index_value

    Der Indexname oder ID-Wert des Indexes. Die Index-ID 0 (Heap) kann nicht angegeben werden. Wenn der Indexname oder die ID zurückgegeben werden soll, fragen Sie die sys.indexes-Katalogsicht ab.

  • index_column_name

    Der Name der Indexspalte, die in den Suchvorgang einbezogen werden soll. Die Angabe von FORCESEEK mit Indexparametern ähnelt der Verwendung von FORCESEEK mit einem INDEX-Hinweis. Sie können jedoch eine genauere Steuerung des vom Abfrageoptimierer verwendeten Zugriffspfads erreichen, indem Sie den Index, in dem die Suche stattfinden soll, und außerdem die Indexspalten angeben, die im Suchvorgang berücksichtigt werden sollen. Der Optimierer kann bei Bedarf zusätzliche Spalten einbeziehen. Wenn beispielsweise ein nicht gruppierter Index angegeben wird, kann der Optimierer neben den angegebenen Spalten auch die Schlüsselspalten gruppierter Indizes verwenden.

Der FORCESEEK-Hinweis kann wie folgt angegeben werden.

Syntax Beispiel BESCHREIBUNG
Ohne Index oder INDEX-Hinweis FROM dbo.MyTable WITH (FORCESEEK) Der Abfrageoptimierer berücksichtigt nur Indexsuchvorgänge für den Zugriff auf die Tabelle oder Sicht über einen beliebigen relevanten Index.
Kombiniert mit einem INDEX-Hinweis FROM dbo.MyTable WITH (FORCESEEK, INDEX (MyIndex)) Der Abfrageoptimierer berücksichtigt nur Indexsuchvorgänge für den Zugriff auf die Tabelle oder Sicht über den angegebenen Index.
Durch Angabe eines Index und von Indexspalten parametrisiert FROM dbo.MyTable WITH (FORCESEEK (MyIndex (col1, col2, col3))) Der Abfrageoptimierer berücksichtigt nur Indexsuchvorgänge für den Zugriff auf die Tabelle oder Sicht über den angegebenen Index mit mindestens den angegebenen Indexspalten.

Beachten Sie bei Verwendung des FORCESEEK-Hinweises (mit oder ohne Parameter) die folgenden Richtlinien:

  • Der Hinweis kann als Tabellenhinweis oder Abfragehinweis angegeben werden. Weitere Informationen zu Abfragehinweisen finden Sie unter Abfragehinweise (Transact-SQL).
  • Zum Anwenden von FORCESEEK auf eine indizierte Sicht muss auch der NOEXPAND-Hinweis angegeben werden.
  • Der Hinweis kann höchstens einmal pro Tabelle oder Sicht angewendet werden.
  • Der Hinweis kann nicht für eine Remotedatenquelle angegeben werden. Fehler 7377 wird zurückgegeben, wenn FORCESEEK mit einem Indexhinweis angegeben wird, Fehler 8180 wird zurückgegeben, wenn FORCESEEK ohne Indexhinweis angegeben wird.
  • Wenn die Verwendung von FORCESEEK bewirkt, dass kein Plan gefunden wird, dann wird der Fehler 8622 zurückgegeben.

Bei Angabe von FORCESEEK mit Indexparametern gelten die folgenden Richtlinien und Einschränkungen:

  • Der Hinweis kann nicht für Tabellen angegeben werden, die Ziel einer INSERT-, UPDATE- oder DELETE-Anweisung sind.
  • Der Hinweis kann nicht zusammen mit einem INDEX-Hinweis oder einem anderen FORCESEEK-Hinweis angegeben werden.
  • Mindestens eine Spalte muss angegeben werden, bei der es sich um die führende Schlüsselspalte handeln muss.
  • Zusätzliche Indexspalten können angegeben, Schlüsselspalten jedoch nicht übersprungen werden. Wenn der angegebene Index beispielsweise die Schlüsselspalten a, b und c enthält, sind FORCESEEK (MyIndex (a)) und FORCESEEK (MyIndex (a, b) als Syntax gültig. Ungültige Syntax wäre FORCESEEK (MyIndex (c)) und FORCESEEK (MyIndex (a, c).
  • Die Reihenfolge der im Hinweis angegebenen Spaltennamen muss der Reihenfolge der Spalten im referenzierten Index entsprechen.
  • Spalten, die nicht in der Indexschlüsseldefinition vorhanden sind, können nicht angegeben werden. Beispielsweise können in einem nicht gruppierten Index nur die definierten Indexschlüsselspalten angegeben werden. Gruppierte Schlüsselspalten, die automatisch in den Index einbezogen werden, können nicht angegeben, aber vom Optimierer verwendet werden.
  • Ein speicheroptimierter xVelocity-Columnstore-Index kann nicht als Indexparameter angegeben werden. Fehler 366 wird zurückgegeben.
  • Nach einer Änderungen der Indexdefinition (z. B. durch Hinzufügen oder Entfernen von Spalten) können Änderungen an den Abfragen erforderlich sein, die auf den betreffenden Index verweisen.
  • Der Hinweis verhindert, dass der Optimierer räumliche oder XML-Indizes für die Tabelle berücksichtigt.
  • Der Hinweis kann nicht zusammen mit dem FORCESCAN-Hinweis angegeben werden.
  • Bei partitionierten Indizes kann die von SQL Server implizit hinzugefügte Partitionierungsspalte nicht im FORCESEEK-Hinweis angegeben werden.

Achtung

Bei Angabe von FORCESEEK mit Parametern wird die Anzahl von Plänen, die vom Optimierer berücksichtigt werden können, stärker eingeschränkt als bei Angabe von FORCESEEK ohne Parameter. Dies kann dazu führen, dass der Plan cannot be generated-Fehler in mehreren Fällen auftritt. In zukünftigen Releases können durch interne Änderungen des Abfrageoptimierers möglicherweise mehr Pläne berücksichtigt werden.

FORCESCAN

Gilt für: SQL Server 2008 R2 (10.50.x) Service Pack 1 und höhere Versionen

Gibt an, dass der Abfrageoptimierer nur einen Indexscan als Zugriffspfad für die referenzierte Tabelle oder Sicht verwenden darf. Der FORCESCAN-Hinweis kann bei Abfragen nützlich sein, in denen der Optimierer die Anzahl betroffener Zeilen unterschätzt und anstelle eines Scanvorgangs einen Suchvorgang auswählt. In diesem Fall ist der für den Vorgang bereitgestellte Arbeitsspeicher zu klein, was sich negativ auf die Abfrageleistung auswirkt.

FORCESCAN kann mit oder ohne INDEX-Hinweis angegeben werden. Bei Kombination mit einem Indexhinweis (INDEX = index_name, FORCESCAN) berücksichtigt der Abfrageoptimierer beim Zugriff auf die referenzierte Tabelle nur Scanzugriffspfade über den angegebenen Index. FORCESCAN kann mit dem Indexhinweis INDEX(0) angegeben werden, um einen Tabellenscan für die Basistabelle zu erzwingen.

Bei partitionierten Tabellen und Indizes wird FORCESCAN angewendet, nachdem Partitionen über eine Abfrageprädikatauswertung gelöscht wurden. Dies bedeutet, dass der Scan nur auf die verbleibenden Partitionen und nicht auf die gesamte Tabelle angewendet wird.

Für den FORCESCAN-Hinweis gelten folgende Einschränkungen:

  • Der Hinweis kann nicht für Tabellen angegeben werden, die Ziel einer INSERT-, UPDATE- oder DELETE-Anweisung sind.
  • Der Hinweis kann nicht mit mehr als einem Indexhinweis verwendet werden.
  • Der Hinweis verhindert, dass der Abfrageoptimierer räumliche oder XML-Indizes in der Tabelle berücksichtigt.
  • Der Hinweis kann nicht für eine Remotedatenquelle angegeben werden.
  • Der Hinweis kann nicht zusammen mit dem FORCESEEK-Hinweis angegeben werden.

HOLDLOCK

Entspricht SERIALIZABLE. Weitere Informationen finden Sie unter SERIALIZABLE weiter unten in diesem Artikel. HOLDLOCK gilt nur für die Tabelle oder Sicht, für die sie angegeben wurde, und nur für die Dauer der Transaktion, die in der Anweisung definiert ist, in der auch HOLDLOCK verwendet wird. HOLDLOCK kann nicht in einer SELECT-Anweisung verwendet werden, die die FOR BROWSE-Option enthält.

IGNORE_CONSTRAINTS

Gilt nur in einer INSERT-Anweisung, wenn die BULK-Option mit OPENROWSET verwendet wird.

Gibt an, dass alle für die Tabelle geltenden Einschränkungen vom Massenimportvorgang ignoriert werden. Standardmäßig überprüft INSERT UNIQUE- und CHECK-Einschränkungen und Primärschlüssel- und Fremdschlüsseleinschränkungen. Wenn für einen Massenimportvorgang IGNORE_CONSTRAINTS angegeben ist, müssen diese Einschränkungen für eine Zieltabelle von INSERT ignoriert werden. Die Einschränkungen UNIQUE, PRIMARY KEY oder NOT NULL können nicht deaktiviert werden.

Sie sollten die Einschränkungen CHECK und FOREIGN KEY z. B. deaktivieren, wenn die Eingabedaten Zeilen enthalten, die Einschränkungen verletzen. Durch das Deaktivieren der Einschränkungen CHECK und FOREIGN KEY können Sie die Daten importieren und dann Transact-SQL-Anweisungen zum Bereinigen der Daten verwenden.

Wenn die CHECK-Einschränkung und die FOREIGN KEY-Einschränkung ignoriert werden, wird jede ignorierte Einschränkung der Tabelle nach dem Vorgang jedoch in der Katalogsicht sys.check_constraints oder sys.foreign_keys als is_not_trusted gekennzeichnet. Irgendwann wird es sinnvoll sein, die Einschränkungen für die gesamte Tabelle zu überprüfen. Wenn die Tabelle vor dem Massenimportvorgang nicht leer war, kann der Aufwand einer erneuten Überprüfung der Einschränkung höher sein als das Anwenden der Einschränkungen CHECK und FOREIGN KEY auf die inkrementellen Daten.

IGNORE_TRIGGERS

Gilt nur in einer INSERT-Anweisung, wenn die BULK-Option mit OPENROWSET verwendet wird.

Gibt an, dass alle für die Tabelle definierten Trigger vom Massenimportvorgang ignoriert werden. Standardmäßig werden Trigger von INSERT angewendet.

Verwenden Sie IGNORE_TRIGGERS nur, wenn Ihre Anwendung nicht von einem Triggern abhängig ist und Leistungsmaximierung ein wichtiger Faktor ist.

NOLOCK

Entspricht READUNCOMMITTED. Weitere Informationen finden Sie unter READUNCOMMITTED weiter unten in diesem Artikel.

Hinweis

Für UPDATE- oder DELETE-Anweisungen: Dieses Feature wird in einer zukünftigen Version von SQL Server entfernt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden.

NOWAIT

IWeist die Datenbank-Engine an, eine Nachricht zurückzugeben, sobald eine Sperre für die Tabelle angetroffen wird. NOWAIT entspricht der Angabe von SET LOCK_TIMEOUT 0 für eine bestimmte Tabelle. Der NOWAIT-Hinweis funktioniert nicht, wenn der TABLOCK-Hinweis ebenfalls enthalten ist. Um eine Abfrage bei Verwendung des TABLOCK-Hinweises ohne Wartezeit zu beenden, stellen Sie der Abfrage stattdessen SET LOCK_TIMEOUT 0; voran.

PAGLOCK

Setzt Seitensperren entweder in solchen Fällen ein, in denen normalerweise einzelne Sperren für Zeilen oder Schlüssel gesetzt werden, oder in Fällen, in denen normalerweise eine einzelne Tabelle gesperrt wird. Verwendet standardmäßig den für den Vorgang geeigneten Sperrmodus. Bei Angabe in Transaktionen mit der Isolationsstufe SNAPSHOT werden Seitensperren nur dann verwendet, wenn PAGLOCK mit anderen Tabellenhinweisen kombiniert wird, die Sperren erfordern, wie z. B. UPDLOCK und HOLDLOCK.

READCOMMITTED

Gibt an, dass Lesevorgänge den Regeln für die Isolationsstufe READ COMMITTED entsprechen, indem entweder Sperren gesetzt werden oder die Zeilenversionsverwaltung verwendet wird. Wenn die Datenbankoption READ_COMMITTED_SNAPSHOT auf OFF festgelegt wurde, fordert die Datenbank-Engine beim Lesen der Daten freigegebene Sperren an und hebt diese Sperren nach Abschluss des Lesevorgangs wieder auf. Wenn die Datenbankoption READ_COMMITTED_SNAPSHOT auf ON festgelegt wurde, fordert die Datenbank-Engine keine Sperren an und verwendet die Zeilenversionsverwaltung. Weitere Informationen zu Isolationsstufen in SQL Server finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

Hinweis

Für UPDATE- oder DELETE-Anweisungen: Dieses Feature wird in einer zukünftigen Version von SQL Server entfernt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden.

READCOMMITTEDLOCK

Gibt an, dass Lesevorgänge den Regeln für die Isolationsstufe READ COMMITTED entsprechen, indem Sperren verwendet werden. Die Datenbank-Engine fordert beim Lesen der Daten freigegebene Sperren an und hebt diese Sperren nach Abschluss des Lesevorgangs wieder auf. Dabei spielt es keine Rolle, welche Einstellung für die Datenbankoption READ_COMMITTED_SNAPSHOT gewählt wurde. Weitere Informationen zu Isolationsstufen in SQL Server finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL). Dieser Hinweis kann nicht für die Zieltabelle einer INSERT-Anweisung angegeben werden. In diesem Fall wird der Fehler 4140 zurückgegeben.

READPAST

Gibt an, dass die Datenbank-Engine keine Zeilen liest, die durch andere Transaktionen gesperrt wurden. Wenn READPAST angegeben ist, werden Sperren auf Zeilenebene übersprungen, Sperren auf Seitenebene allerdings nicht. Das bedeutet: anstatt die aktuelle Transaktion zu blockieren, überspringt die Datenbank-Engine die Zeilen, bis die Sperren aufgehoben werden. Nehmen Sie z. B. an, die T1-Tabelle enthält eine Spalte mit einzelnen ganzen Zahlen und den Werten 1, 2, 3, 4, 5. Wenn Transaktion A die Werte 3 bis 8 ändert, jedoch noch kein Commit für sie ausgeführt wurde, liefert SELECT * FROM T1 (READPAST) die Werte 1, 2, 4, 5. READPAST dient hauptsächlich zur Verringerung von Sperrkonflikten beim Implementieren einer Arbeitswarteschlange, die eine SQL Server-Tabelle verwendet. Ein Warteschlangenlesevorgang, der READPAST verwendet, lässt durch andere Transaktionen gesperrte Warteschlangeneinträge aus und liest den nächsten verfügbaren Warteschlangeneintrag. Damit entfällt die Wartezeit, bis andere Transaktionen ihre Sperren freigeben.

READPAST kann für jede Tabelle angegeben werden, auf die in einer UPDATE- oder DELETE-Anweisung verwiesen wird, sowie für jede Tabelle, auf die in einer FROM-Klausel verwiesen wird. Wenn Sie den READPAST-Hinweis in einer UPDATE-Anweisung angeben, wird er nur beim Lesen von Daten angewendet, um die zu aktualisierenden Datensätze zu identifizieren. Dies gilt unabhängig davon, an welcher Stelle der Anweisung der Hinweis angegeben ist. READPAST kann nicht für Tabellen in der INTO-Klausel einer INSERT-Anweisung angegeben werden. Aktualisierungs- oder Löschvorgänge, die READPAST verwenden, können beim Lesen von Fremdschlüsseln oder indizierten Sichten sowie beim Ändern sekundärer Indizes zu Blockierungen führen.

READPAST kann nur in Transaktionen angegeben werden, die mit den Isolationsstufen READ COMMITTED oder REPEATABLE READ arbeiten. Bei Angabe in Transaktionen mit der Isolationsstufe SNAPSHOT muss READPAST mit anderen Tabellenhinweisen kombiniert werden, die Sperren erfordern, wie z. B. UPDLOCK und HOLDLOCK.

Der READPAST-Tabellenhinweis kann nicht angegeben werden, wenn die Datenbankoption READ_COMMITTED_SNAPSHOTauf ON festgelegt ist und eine der folgenden Bedingungen zutrifft:

  • Die Transaktionsisolationsstufe der Sitzung ist READ COMMITTED.
  • Der READCOMMITTED-Tabellenhinweis wird ebenfalls in der Abfrage angegeben.

Um in diesen Fällen den READPAST-Hinweis anzugeben, entfernen Sie den READCOMMITTED-Tabellenhinweis (sofern vorhanden) und schließen den READCOMMITTEDLOCK-Tabellenhinweis in die Abfrage ein.

READUNCOMMITTED

Gibt an, dass Dirty Reads zulässig sind. Es werden keine gemeinsamen Sperren vergeben, um andere Transaktionen daran zu hindern, die von der aktuellen Transaktion gelesenen Daten zu ändern. Darüber hinaus blockieren von anderen Transaktionen gesetzte exklusive Sperren die aktuelle Transaktion nicht beim Lesen der gesperrten Daten. Das kann eine höhere Parallelität, aber gleichzeitig zur Folge haben, dass Datenänderungen gelesen werden, für die andere Transaktionen dann ein Rollback ausführen. Dadurch können Fehler in der Transaktion auftreten, Daten angezeigt werden, für die nie ein Commit ausgeführt wurde, oder Datensätze zwei Mal (oder gar nicht) dargestellt werden.

READUNCOMMITTED- und NOLOCK-Hinweise gelten nur für Datensperren. Alle Abfragen, auch solche mit READUNCOMMITTED- und NOLOCK-Hinweisen, aktivieren bei der Kompilierung und Ausführung Sperren des Typs „Sch-S“ (Schemastabilität). Daher werden Abfragen gesperrt, wenn eine gleichzeitige Transaktion eine Schemaänderungssperre (Sch-M) für die Tabelle aufrechterhält. Beispielsweise aktiviert ein DDL-Vorgang (Data Definition Language, Datendefinitionssprache) eine Sch-S-Sperre, bevor die Schemainformationen für die Tabelle geändert werden. Alle parallel ausgeführten Abfragen (Abfragen mit READUNCOMMITTED- oder NOLOCK-Hinweisen eingeschlossen) werden blockiert, wenn sie versuchen, eine Sch-S-Sperre anzufordern. Umgekehrt blockiert eine Abfrage, die eine Sch-S-Sperre aufrechterhält, eine gleichzeitige Transaktion, die versucht, eine Sch-M-Sperre zu errichten.

READUNCOMMITTED und NOLOCK können nicht für Tabellen angegeben werden, die durch INSERT-, UPDATE- oder DELETE-Vorgänge geändert wurden. Der SQL Server-Abfrageoptimierer ignoriert die READUNCOMMITTED- und NOLOCK-Hinweise in der FROM-Klausel, die für die Zieltabelle einer UPDATE- oder DELETE-Anweisung gelten.

Hinweis

Die Unterstützung für die Verwendung der READUNCOMMITTED- und NOLOCK-Hinweise in der FROM-Klausel, die sich auf die Zieltabelle einer UPDATE- oder DELETE-Anweisung beziehen, wird in einer zukünftigen Version von SQL Server entfernt. Vermeiden Sie die Verwendung dieser Hinweise in diesem Kontext beim Entwickeln neuer Anwendungen, und planen Sie die Änderung von Anwendungen, in denen sie aktuell verwendet werden.

Sie können Konflikte zwischen Sperren minimieren und zugleich Transaktionen vor Dirty Reads von Datenänderungen, für die kein Commit ausgeführt wurde, auf eine der folgenden Weisen schützen:

  • Verwenden der READ COMMITTED-Isolationsstufe bei Festlegung der Datenbankoption READ_COMMITTED_SNAPSHOT auf ON
  • Isolationsstufe SNAPSHOT

Weitere Informationen zu Isolationsstufen in SQL Server finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

Hinweis

Wenn READUNCOMMITTED angegeben wird und Sie die Fehlermeldung 601 erhalten, lösen Sie den Fehler wie einen Deadlockfehler (Fehlermeldung 1205) auf, und wiederholen Sie die Anweisung.

REPEATABLEREAD

Legt fest, dass ein Scan mit derselben Sperrsemantik wie eine Transaktion durchgeführt wird, die auf der Isolationsstufe REPEATABLE READ ausgeführt wird. Weitere Informationen zu Isolationsstufen in SQL Server finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

ROWLOCK

Gibt an, das Zeilensperren in solchen Fällen gesetzt werden, in denen normalerweise Seiten- oder Tabellensperren gesetzt werden. Bei Angabe in Transaktionen mit der Isolationsstufe SNAPSHOT werden Zeilensperren nur dann verwendet, wenn ROWLOCK mit anderen Tabellenhinweisen kombiniert wird, die Sperren erfordern, wie z. B. UPDLOCK und HOLDLOCK. ROWLOCK kann nicht mit einer Tabelle verwendet werden, die über einen gruppierten Columnstore-Index verfügt. Im folgenden Beispiel wird Fehler 651 an die Anwendung zurückgegeben.

UPDATE [dbo].[FactResellerSalesXL_CCI] WITH (ROWLOCK)
SET UnitPrice = 50
WHERE ProductKey = 150;

SERIALIZABLE

Entspricht HOLDLOCK. Verstärkt die Einschränkung von freigegebenen Sperren, indem sie aufrechterhalten werden, bis eine Transaktion abgeschlossen ist (anstatt die freigegebene Sperre aufzuheben, sobald die benötigte Tabelle oder Datenseite nicht mehr gebraucht wird, ganz gleich, ob die Transaktion abgeschlossen ist oder nicht). Der Scan wird mit derselben Semantik wie eine Transaktion durchgeführt, die auf der Isolationsstufe SERIALIZABLE ausgeführt wird. Weitere Informationen zu Isolationsstufen in SQL Server finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

SNAPSHOT

Gilt für: SQL Server 2014 (12.x) und höhere Versionen

Auf die speicheroptimierte Tabelle wird mit der Isolationsstufe SNAPSHOT zugegriffen. SNAPSHOT kann nur mit speicheroptimierten Tabellen verwendet werden (nicht mit datenträgerbasierten Tabellen), wie im folgenden Beispiel gezeigt. Weitere Informationen finden Sie unter Einführung in speicheroptimierte Tabellen.

SELECT *
FROM dbo.Customers AS c WITH (SNAPSHOT)
LEFT JOIN dbo.[Order History] AS oh
    ON c.customer_id=oh.customer_id;

SPATIAL_WINDOW_MAX_CELLS = <integer_value>

Gilt für: SQL Server 2012 (11.x) und höhere Versionen

Gibt die maximale Anzahl der Zellen an, die für die Mosaikbearbeitung eines geometry- oder geography-Objekts verwendet werden sollen. <integer_value> ist eine ganze Zahl zwischen 1 und 8192.

Mit dieser Option können Sie die Ausführungszeit von Abfragen optimieren, indem Sie den Zusammenhang zwischen der Ausführungszeit des primären und des sekundären Filters kontrollieren. Ein höherer Wert verringert die Ausführungszeit des sekundären Filters, erhöht jedoch die Ausführungszeit des primären Filters. Ein niedrigerer Wert verringert die Ausführungszeit des primären Filters, erhöht jedoch die Ausführungszeit des sekundären Filters. Bei räumlichen Daten mit größerer Dichte sollte ein höherer Wert durch bessere Angleichung an den primären Filter und Verringerung der Ausführungszeit des sekundären Filters in einer niedrigeren Ausführungszeit resultieren. Bei Daten mit geringer Dichte verringert ein niedrigerer Wert die Ausführungszeit des primären Filters.

Diese Option funktioniert für sowohl manuelle als auch automatische Rastermosaike.

TABLOCK

Gibt an, dass die abgerufene Sperre auf Tabellenebene aktiviert wird. Der Typ der abgerufenen Sperre hängt von der ausgeführten Anweisung ab. Beispielsweise kann eine SELECT-Anweisung eine gemeinsame Sperre abrufen. Bei Angabe von TABLOCK wird die gemeinsame Sperre auf die gesamte Tabelle statt auf Zeilen- oder Seitenebene angewendet. Wird zusätzlich HOLDLOCK angegeben, wird die Tabellensperre bis zum Transaktionsende aufrechterhalten.

Wenn Sie Daten mit der INSERT INTO <target_table> SELECT <columns> FROM <source_table>-Anweisung in einen Heap importieren, können Sie eine minimale Protokollierung und optimale Sperrung für die Anweisung aktivieren, indem Sie den TABLOCK-Hinweis für die Zieltabelle angeben. Außerdem muss das Wiederherstellungsmodell der Datenbank auf einfach oder massenprotokolliert festgelegt werden. Der TABLOCK-Hinweis ermöglicht außerdem parallele Einfügungen in Heaps oder gruppierte Columnstore-Indizes. Weitere Informationen finden Sie unter INSERT (Transact-SQL).

Bei Verwendung mit dem OPENROWSET-Massenrowsetanbieter zum Importieren von Daten in eine Tabelle ermöglicht TABLOCK mehreren Clients das gleichzeitige Laden von Daten in die Zieltabelle mit optimierter Protokollierung und Sperrung. Weitere Informationen finden Sie unter Voraussetzungen für die minimale Protokollierung beim Massenimport.

TABLOCKX

Gibt an, dass für die Tabelle eine exklusive Sperre verwendet wird.

UPDLOCK

Gibt an, dass Updatesperren zu verwenden und aufrechtzuerhalten sind, bis die Transaktion abgeschlossen ist. UPDLOCK erstellt Updatesperren für Lesevorgänge nur auf Zeilen- oder Seitenebene. Wenn UPDLOCK mit TABLOCK kombiniert wird oder aus einem anderen Grund eine Sperre auf Tabellenebene erstellt wird, wird stattdessen eine exklusive Sperre (X) erstellt.

Bei Angabe von UPDLOCK werden die Isolationsstufenhinweise READCOMMITTED und READCOMMITTEDLOCK ignoriert. Wenn beispielsweise die Isolationsstufe der Sitzung auf SERIALIZABLE festgelegt ist und eine Abfrage (UPDLOCK, READCOMMITTED) angibt, wird der READCOMMITTED-Hinweis ignoriert, und die Transaktion wird mit der Isolationsstufe SERIALIZABLE ausgeführt.

XLOCK

Gibt an, dass exklusive Sperren zu verwenden und aufrechtzuerhalten sind, bis die Transaktion abgeschlossen ist. Bei Angabe mit ROWLOCK, PAGLOCK oder TABLOCK gelten die exklusiven Sperren für die entsprechende Granularitätsebene.

Bemerkungen

Tabellenhinweise werden ignoriert, wenn der Abfrageplan nicht auf die Tabelle zugreift. Dies ist möglicherweise darauf zurückzuführen, dass der Optimierer überhaupt nicht auf die Tabelle oder stattdessen auf eine indizierte Sicht zugreift. In letzterem Fall kann der Zugriff auf eine indizierte Sicht verhindert werden, indem der Abfragehinweis OPTION (EXPAND VIEWS) verwendet wird.

Alle Sperrhinweise werden an alle Tabellen und Sichten weitergeleitet, auf die der Abfrageplan zugreift, auch an Tabellen und Sichten, auf die in einer Sicht verwiesen wird. Zusätzlich nimmt SQL Server die entsprechenden Sperrkonsistenzprüfungen vor.

Die Sperrhinweise ROWLOCK, UPDLOCK und XLOCK, die Sperren auf Zeilenebene anfordern, richten Sperren ggf. für Indexschlüssel und nicht für die eigentlichen Datenzeilen ein. Wenn eine Tabelle beispielsweise über einen nicht gruppierten Index verfügt und eine SELECT-Anweisung, die einen Sperrhinweis verwendet, von einem abdeckenden Index verarbeitet wird, wird eine Sperre für den Indexschlüssel im abdeckenden Index angefordert, statt für die Datenzeile in der Basistabelle.

Falls eine Tabelle berechnete Spalten enthält und die berechneten Spalten von Ausdrücken oder Funktionen berechnet werden, die auf Spalten anderer Tabellen zugreifen, werden auf diese Tabellen keine Tabellenhinweise angewendet, und es erfolgt keine Weitergabe. Angenommen, für eine Tabelle in der Abfrage wird der NOLOCK-Tabellenhinweis angegeben. Diese Tabelle enthält berechnete Spalten, die von einer Kombination aus Ausdrücken und Funktionen berechnet werden, die auf Spalten in einer anderen Tabelle zugreifen. Die Tabellen, auf die die Ausdrücke und Funktionen verweisen, verwenden den Tabellenhinweis NOLOCK nicht, wenn auf sie zugegriffen wird.

SQL Server gestattet für jede Tabelle in der FROM-Klausel maximal einen Tabellenhinweis aus jeder der folgenden Gruppen:

  • Granularitätshinweise: PAGLOCK, NOLOCK, READCOMMITTEDLOCK, ROWLOCK, TABLOCK oder TABLOCKX.
  • Isolationsstufenhinweise: HOLDLOCK, NOLOCK, READCOMMITTED, REPEATABLEREAD, SERIALIZABLE.

Gefilterte Indexhinweise

Ein gefilterter Index kann als Tabellenhinweis verwendet werden, bewirkt jedoch, dass der Abfrageoptimierer den Fehler 8622 generiert, wenn er nicht alle Zeilen abdeckt, die durch die Abfrage ausgewählt werden. Es folgt ein Beispiel für einen ungültigen gefilterten Indexhinweis. Im folgenden Beispiel wird der gefilterte Index FIBillOfMaterialsWithComponentID erstellt und anschließend als Indexhinweis für eine SELECT-Anweisung verwendet. Das gefilterte Indexprädikat schließt Datenzeilen für die ComponentIDs 533, 324 und 753 ein. Das Abfrageprädikat schließt ebenfalls Datenzeilen für die ComponentIDs 533, 324 und 753 ein, erweitert das Resultset jedoch um die ComponentIDs 855 und 924, die nicht im gefilterten Index enthalten sind. Deshalb kann der Abfrageoptimierer den gefilterten Indexhinweis nicht verwenden und generiert den Fehler 8622. Weitere Informationen finden Sie unter erstellen gefilterter Indizes.

IF EXISTS (SELECT name FROM sys.indexes
    WHERE name = N'FIBillOfMaterialsWithComponentID'
    AND object_id = OBJECT_ID(N'Production.BillOfMaterials'))
DROP INDEX FIBillOfMaterialsWithComponentID
    ON Production.BillOfMaterials;
GO
CREATE NONCLUSTERED INDEX "FIBillOfMaterialsWithComponentID"
    ON Production.BillOfMaterials (ComponentID, StartDate, EndDate)
    WHERE ComponentID IN (533, 324, 753);
GO
SELECT StartDate, ComponentID FROM Production.BillOfMaterials
    WITH(INDEX (FIBillOfMaterialsWithComponentID))
    WHERE ComponentID in (533, 324, 753, 855, 924);
GO

Der Abfrageoptimierer berücksichtigt einen Indexhinweis nur dann, wenn die SET-Optionen die erforderlichen Werte für die gefilterten Indizes enthalten. Weitere Informationen finden Sie unter CREATE INDEX (Transact-SQL).

Verwenden von NOEXPAND

NOEXPAND gilt nur für indizierte Sichten. Eine indizierte Sicht ist eine Sicht, auf der ein eindeutiger gruppierter Index erstellt wurde. Wenn eine Abfrage Verweise auf Spalten enthält, die in einer indizierten Sicht und in Basistabellen vorhanden sind, und der Abfrageoptimierer festlegt, dass die Verwendung der indizierten Sicht die beste Methode zum Ausführen der Abfrage darstellt, verwendet der Optimierer den Index der Sicht. Diese Funktionalität wird als Abgleich der indizierten Sicht bezeichnet. Vor SQL Server 2016 (13.x) Service Pack 1 wurde die automatische Verwendung einer indizierten Sicht durch den Abfrageoptimierer nur in bestimmten Editionen von SQL Server unterstützt. Da alle Editionen die automatische Verwendung einer indizierten Ansicht unterstützen. Azure SQL-Datenbank und Azure SQL Managed Instance unterstützen auch die automatische Verwendung indizierter Ansichten ohne Angabe des NOEXPAND-Hinweises.

Weitere Informationen finden Sie unter Handbuch zur Architektur der Abfrageverarbeitung.

Eine Liste der Features, die von den SQL Server-Editionen auf Windows unterstützt werden, finden Sie hier:

Damit der Abfrageoptimierer indizierte Sichten für den Abgleich berücksichtigt oder eine indizierte Sicht verwendet, auf die mit dem NOEXPAND-Hinweis verwiesen wird, müssen die folgenden SET-Optionen auf ON festgelegt sein.

  • ANSI_NULLS
  • ANSI_PADDING
  • ANSI_WARNINGS
  • ARITHABORT 1
  • CONCAT_NULL_YIELDS_NULL
  • QUOTED_IDENTIFIER

1 ARITHABORT wird implizit auf ON festgelegt, wenn ANSI_WARNINGS auf ON festgelegt wurde. Es ist daher nicht erforderlich, diese Einstellung manuell anzupassen.

Auch muss die Option NUMERIC_ROUNDABORT auf OFF festgelegt sein.

Damit der Abfrageoptimierer einen Index für eine indizierte Sicht verwendet, geben Sie die Option NOEXPAND an. Dieser Hinweis kann nur dann verwendet werden, wenn die Sicht ebenfalls in der Abfrage angegeben wurde. SQL Server bietet keinen Hinweis, um die Verwendung einer bestimmten indizierten Sicht in einer Abfrage zu erzwingen, die die Sicht nicht direkt in der FROM-Klausel benennt. Der Abfrageoptimierer berücksichtigt jedoch die Verwendung indizierter Sichten, auch wenn in der Abfrage nicht direkt auf sie verwiesen wird. Die SQL Server-Datenbank-Engine erstellt Statistiken in einer indizierten Sicht nur automatisch, wenn ein NOEXPAND-Tabellenhinweis verwendet wird. Wenn Sie diesen Hinweis auslassen, kann dies zu Ausführungsplanwarnungen aufgrund fehlender Statistiken führen, die durch manuelles Erstellen von Statistiken nicht behoben werden können.

Während der Abfrageoptimierung nutzt die Datenbank-Engine automatisch oder manuell erstellte Sichtstatistiken, wenn die Abfrage direkt auf die Sicht verweist und der NOEXPAND-Hinweis verwendet wird.

Verwenden eines Tabellenhinweises als Abfragehinweis

Tabellenhinweise können mit der OPTION (TABLE HINT)-Klausel auch als Abfragehinweis angegeben werden. Es wird empfohlen, einen Tabellenhinweis nur im Kontext einer Planhinweisliste als Abfragehinweis zu verwenden. Für Ad-hoc-Abfragen geben Sie diese Hinweise nur als Tabellenhinweise an. Weitere Informationen finden Sie unter Abfragehinweise (Transact-SQL).

Berechtigungen

Die KEEPIDENTITY-, IGNORE_CONSTRAINTS- und IGNORE_TRIGGERS-Hinweise erfordern ALTER-Berechtigungen in der Tabelle.

Beispiele

A. Verwenden des TABLOCK-Hinweises zum Angeben einer Sperrmethode

Im folgenden Beispiel wird angegeben, dass eine freigegebene Sperre für die Production.Product-Tabelle in der AdventureWorks2022-Datenbank eingerichtet und bis zum Ende der UPDATE-Anweisung aufrechterhalten wird.

UPDATE Production.Product
WITH (TABLOCK)
SET ListPrice = ListPrice * 1.10
WHERE ProductNumber LIKE 'BK-%';
GO

B. Verwenden des FORCESEEK-Hinweises zum Angeben eines Indexsuchvorgangs

Im folgenden Beispiel wird der FORCESEEK-Hinweis ohne Indexangabe verwendet, um den Abfrageoptimierer zu zwingen, eine Indexsuche für Tabelle Sales.SalesOrderDetail in der AdventureWorks2022-Datenbank durchzuführen.

SELECT *
FROM Sales.SalesOrderHeader AS h
INNER JOIN Sales.SalesOrderDetail AS d WITH (FORCESEEK)
    ON h.SalesOrderID = d.SalesOrderID
WHERE h.TotalDue > 100
AND (d.OrderQty > 5 OR d.LineTotal < 1000.00);
GO

Das folgende Beispiel verwendet den FORCESEEK-Hinweis mit einem Index, um den Abfrageoptimierer zu zwingen, eine Indexsuche für den angegebenen Index und die Indexspalte durchzuführen.

SELECT h.SalesOrderID, h.TotalDue, d.OrderQty
FROM Sales.SalesOrderHeader AS h
    INNER JOIN Sales.SalesOrderDetail AS d
    WITH (FORCESEEK (PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID (SalesOrderID)))
    ON h.SalesOrderID = d.SalesOrderID
WHERE h.TotalDue > 100
AND (d.OrderQty > 5 OR d.LineTotal < 1000.00);
GO

C. Verwenden des FORCESCAN-Hinweises zum Angeben eines Indexscans

Im folgenden Beispiel wird der Abfrageoptimierer mithilfe des FORCESCAN-Hinweises gezwungen, einen Scanvorgang für Tabelle Sales.SalesOrderDetail in der AdventureWorks2022-Datenbank durchzuführen.

SELECT h.SalesOrderID, h.TotalDue, d.OrderQty
FROM Sales.SalesOrderHeader AS h
    INNER JOIN Sales.SalesOrderDetail AS d
    WITH (FORCESCAN)
    ON h.SalesOrderID = d.SalesOrderID
WHERE h.TotalDue > 100
AND (d.OrderQty > 5 OR d.LineTotal < 1000.00);

Zugehöriger Inhalt