Freigeben über

Tabellenhinweise (Transact-SQL)

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed InstanceSQL-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 -Klausel der DML-Anweisung angegeben und wirken sich nur auf die Tabelle oder Ansicht aus, auf die in dieser Klausel verwiesen wird.

Caution

Da der SQL Server Abfrageoptimierer in der Regel den besten Ausführungsplan für eine Abfrage auswählt, empfehlen wir, dass Hinweise nur als letztes Mittel von erfahrenen Entwicklern und Datenbankadministratoren verwendet werden.

Gilt für:

  • DELETE
  • INSERT
  • SELECT
  • UPDATE
  • MERGE

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
}

Arguments

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

Mit einigen Ausnahmen werden Tabellenhinweise nur dann in der -Klausel unterstützt, wenn die Hinweise mit dem schlüsselwort angegeben werden. Tabellenhinweise müssen zudem mit Klammern angegeben werden.

Important

Das Auslassen des Schlüsselworts WITH 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 zulässig: , , , , , , , , , , , , , und . Wenn bei diesen Tabellenhinweisen nicht das -Schlüsselwort festgelegt wird, sollten sie separat angegeben werden. Beispiel:

FROM t (TABLOCK)

Wenn der Hinweis mit einer anderen Option angegeben wird, muss der Hinweis mit dem schlüsselwort angegeben werden:

FROM t WITH (TABLOCK, INDEX(myindex))

Es wird empfohlen, Tabellenhinweise durch Kommas voneinander zu trennen.

Important

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. gilt nur für indizierte Sichten. Weitere Informationen finden Sie unter Verwenden von NOEXPAND.

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

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

Falls ein gruppierter Index vorhanden ist, erzwingt eine Überprüfung des gruppierten Index, und erzwingt eine Überprüfung des gruppierten Index oder eine Suche im gruppierten Index. Falls kein gruppierter Index vorhanden ist, erzwingt einen Tabellenscan, und 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. Wenn die Auflistung von gekennzeichneten Indizes nicht alle Spalten enthält, auf die von der Abfrage verwiesen wird, wird ein Abruf ausgeführt, um die verbleibenden Spalten abzurufen, nachdem die SQL Server-Datenbank-Engine alle indizierten Spalten abgerufen hat.

Note

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 Index-ORing für eine Tabelle mit einem angegebenen Indexhinweis nicht zulässig.

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

KEEPIDENTITY

Gilt nur in einer Anweisung, wenn die Option mit OPENROWSET(BULK) verwendet wird.

Gibt an, dass der oder die Identitätswerte in der importierten Datendatei für die Identitätsspalte verwendet werden sollen. Wenn nicht angegeben ist, werden die Identitätswerte für diese Spalte überprüft, aber nicht importiert, und der Abfrageoptimierer weist automatisch eindeutige Werte basierend auf dem Startwert und den während der Tabellenerstellung angegebenen Inkrementwerten zu.

Important

Wenn die Datendatei keine Werte für die Identitätsspalte in der Tabelle oder Ansicht enthält und die Identitätsspalte nicht die letzte Spalte in der Tabelle ist, müssen Sie die Identitätsspalte überspringen. Weitere Informationen finden Sie unter Use a format file to skip a data field (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, das diesen Hinweis in einer INSERT ... SELECT * FROM OPENROWSET(BULK...)-Anweisung verwendet, finden Sie unter Keep-Identitätswerte beim Massenimport von Daten (SQL Server).

Informationen zum Überprüfen des Identitätswerts für eine Tabelle finden Sie unter DBCC CHECKIDENT.

KEEPDEFAULTS

Gilt nur in einer Anweisung, wenn die Option mit OPENROWSET (BULK) verwendet wird.

Gibt das Einfügen des Standardwerts einer Tabellenspalte an, falls vorhanden, anstelle von , wenn der Datensatz keinen Wert für die Spalte aufweist.

Ein Beispiel, das diesen Hinweis in einer INSERT ... SELECT * FROM OPENROWSET(BULK...)-Anweisung verwendet, finden Sie unter Keep nulls oder Standardwerte 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.

Note

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 -Katalogsicht ab.

  • index_column_name

    Der Name der Indexspalte, die in den Suchvorgang einbezogen werden soll. Die Angabe von mit Indexparametern ähnelt der Verwendung von mit einem -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 weitere Spalten in Betracht ziehen. Wenn beispielsweise ein nicht gruppierter Index angegeben wird, kann der Optimierer zusätzlich zu den angegebenen Spalten gruppierte Indexschlüsselspalten verwenden.

Der -Hinweis kann wie folgt angegeben werden.

Syntax Example Description
Ohne Index oder -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 -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 -Hinweises (mit oder ohne Parameter) die folgenden Richtlinien:

  • Der Hinweis kann als Tabellenhinweis oder Abfragehinweis angegeben werden. Weitere Informationen zu Abfragehinweisen finden Sie unter Query-Hinweise (Transact-SQL).
  • Zum Anwenden von auf eine indizierte Sicht muss auch der -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 mit einem Indexhinweis angegeben wird, Fehler 8180 wird zurückgegeben, wenn ohne Indexhinweis angegeben wird.
  • Wenn keine Pläne gefunden werden, wird fehler 8622 zurückgegeben.

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

  • Der Hinweis kann für eine Tabelle, die das Ziel einer , oder Anweisung ist, nicht angegeben werden.
  • Der Hinweis kann nicht zusammen mit einem -Hinweis oder einem anderen -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 , und enthält, sind und als Syntax gültig. Ungültige Syntax wäre und .
  • 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 im Index enthalten sind, können nicht angegeben werden, können aber vom Optimierer verwendet werden.
  • Ein speicheroptimierter xVelocity-Columnstore-Index kann nicht als Indexparameter angegeben werden. Fehler 366 wird zurückgegeben.
  • Das Ändern der Indexdefinition (z. B. durch Hinzufügen oder Entfernen von Spalten) erfordert möglicherweise Änderungen an den Abfragen, die auf diesen 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 -Hinweis angegeben werden.
  • Bei partitionierten Indizes kann die Partitionierungsspalte, die implizit von SQL Server hinzugefügt wurde, nicht im hinweis FORCESEEK angegeben werden.

Caution

Bei Angabe von mit Parametern wird die Anzahl von Plänen, die vom Optimierer berücksichtigt werden können, stärker eingeschränkt als bei Angabe von ohne Parameter. Dies kann dazu führen, dass in mehr Fällen ein Fehler auftritt.

FORCESCAN

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

Gibt an, dass der Abfrageoptimierer nur einen Indexscan als Zugriffspfad für die referenzierte Tabelle oder Sicht verwenden darf. Der -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.

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

Bei partitionierten Tabellen und Indizes wird angewendet, nachdem Partitionen durch die Abfrage-Prädikatauswertung eliminiert wurden. Dies bedeutet, dass der Scan nur auf die verbleibenden Partitionen und nicht auf die gesamte Tabelle angewendet wird.

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

  • Der Hinweis kann für eine Tabelle, die das Ziel einer , oder Anweisung ist, nicht angegeben werden.
  • 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 -Hinweis angegeben werden.

HOLDLOCK

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

IGNORE_CONSTRAINTS

Gilt nur in einer Anweisung, wenn die Option mit OPENROWSET (BULK) verwendet wird.

Gibt an, dass der Massenimportvorgang alle Einschränkungen für die Tabelle ignoriert. Standardmäßig überprüft Eindeutige Einschränkungen und Checkeinschränkungen und Neben- und Fremdschlüsseleinschränkungen. Wenn für einen Massenimportvorgang angegeben wird, muss diese Einschränkungen für eine Zieltabelle ignorieren. Sie können , oder Einschränkungen nicht deaktivieren.

Möglicherweise möchten Sie und Einschränkungen deaktivieren, wenn die Eingabedaten Zeilen enthalten, die gegen Einschränkungen verstoßen. Durch Deaktivieren der Einschränkungen CHECK und FOREIGN KEY können Sie die Daten importieren und dann Transact-SQL Anweisungen verwenden, um die Daten zu bereinigen.

Wenn jedoch und Einschränkungen ignoriert werden, wird jede ignorierte Einschränkung für die Tabelle nach dem Vorgang als in der sys.check_constraints- oder sys.foreign_keys Katalogansicht markiert. 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 die Kosten für die Neuvalidierung der Einschränkung die Kosten für die Anwendung und Einschränkungen auf die inkrementellen Daten überschreiten.

IGNORE_TRIGGERS

Gilt nur in einer Anweisung, wenn die Option mit OPENROWSET (BULK) verwendet wird.

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

Verwenden Sie nur, wenn Ihre Anwendung nicht von Triggern abhängt und die Leistung maximiert wird.

NOLOCK

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

Note

For UPDATE or DELETE statements: This feature will be removed in a future version of SQL Server. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden.

NOWAIT

Weist die Datenbank-Engine an, eine Nachricht zurückzugeben, sobald eine Sperre in der Tabelle aufgetreten ist. entspricht der Angabe von für eine bestimmte Tabelle. Der -Hinweis funktioniert nicht, wenn der -Hinweis ebenfalls enthalten ist. Um eine Abfrage bei Verwendung des -Hinweises ohne Wartezeit zu beenden, stellen Sie der Abfrage stattdessen 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 werden Seitensperren nur dann verwendet, wenn mit anderen Tabellenhinweisen kombiniert wird, die Sperren erfordern, wie z. B. und .

READCOMMITTED

Gibt an, dass Lesevorgänge den Regeln für die Isolationsebene entsprechen, indem sie entweder Sperren oder Zeilenversionsverwaltung verwenden. Wenn die Datenbankoption READ_COMMITTED_SNAPSHOTOFF ist, erwirbt die Datenbank-Engine freigegebene Sperren, wenn Daten gelesen werden, und gibt diese Sperren frei, wenn der Lesevorgang abgeschlossen ist. Wenn die Datenbankoption READ_COMMITTED_SNAPSHOTON ist, erhält die Datenbank-Engine keine Sperren und verwendet Zeilenversionsverwaltung. Weitere Informationen zu Isolationsstufen finden Sie unter SET TRANSACTION ISOLATION LEVEL.

Note

For UPDATE or DELETE statements: This feature will be removed in a future version of SQL Server. 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 die Regeln für die isolationsstufe mithilfe der Sperrung einhalten. Die Datenbank-Engine erhält freigegebene Sperren, wenn Daten gelesen werden, und gibt diese Sperren frei, wenn der Lesevorgang abgeschlossen ist, unabhängig von der Einstellung der Datenbankoption READ_COMMITTED_SNAPSHOT Datenbank. Weitere Informationen zu Isolationsstufen finden Sie unter SET TRANSACTION ISOLATION LEVEL. Dieser Hinweis kann in der Zieltabelle einer -Anweisung nicht angegeben werden. Fehler 4140 wird zurückgegeben.

READPAST

Gibt an, dass die Datenbank-Engine keine Zeilen lesen, die durch andere Transaktionen gesperrt sind. Wenn angegeben ist, werden Sperren auf Zeilenebene übersprungen, Sperren auf Seitenebene allerdings nicht. Das heißt, die Datenbank-Engine überspringt die Zeilen, anstatt die aktuelle Transaktion zu blockieren, bis die Sperren freigegeben werden. Nehmen Sie z. B. an, die -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 die Werte 1, 2, 4, 5. READPAST wird in erster Linie verwendet, um die Sperrung von Inhalten bei der Implementierung einer Arbeitswarteschlange zu reduzieren, die eine SQL Server Tabelle verwendet. Ein Warteschlangenlesevorgang, der 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.

kann für jede Tabelle angegeben werden, auf die in einer - oder -Anweisung verwiesen wird, und für jede Tabelle, auf die in einer Klausel verwiesen wird. Wenn in einer -Anweisung angegeben, wird nur beim Lesen von Daten angewendet, um zu identifizieren, welche Datensätze aktualisiert werden sollen, unabhängig davon, wo in der anweisung angegeben ist. kann für Tabellen in der -Klausel einer -Anweisung nicht angegeben werden. Aktualisierungs- oder Löschvorgänge, die verwenden, können beim Lesen von Fremdschlüsseln oder indizierten Ansichten oder beim Ändern sekundärer Indizes blockiert werden.

können nur in Transaktionen angegeben werden, die auf - oder Isolationsebenen ausgeführt werden.

Der Tabellenhinweis kann nicht angegeben werden, wenn die Option Datenbank auf festgelegt ist und eine der folgenden Bedingungen zutrifft:

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

Um in diesen Fällen den -Hinweis anzugeben, entfernen Sie den -Tabellenhinweis (sofern vorhanden) und schließen den -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. Dies kann Fehler für Ihre Transaktion generieren, Benutzern Daten präsentieren, die nie zugesichert wurden, oder dazu führen, dass Benutzer Datensätze zweimal (oder gar nicht) sehen.

- und -Hinweise gelten nur für Datensperren. Alle Abfragen, einschließlich Abfragen mit und Hinweise, erwerben Sch-S (Schemastabilität) sperren während der Kompilierung und Ausführung. 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 gleichzeitigen Abfragen, einschließlich Abfragen, die mit oder Hinweisen ausgeführt werden, werden blockiert, wenn Sie versuchen, eine Sch-S Sperre abzurufen. Umgekehrt blockiert eine Abfrage, die eine Sch-S-Sperre aufrechterhält, eine gleichzeitige Transaktion, die versucht, eine Sch-M-Sperre zu errichten.

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

Note

Unterstützung für die Verwendung der READUNCOMMITTED und NOLOCK Hinweise in der klausel FROM, die für die Zieltabelle einer UPDATE oder DELETE Anweisung gelten, 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 das Sperren von Inhalten minimieren, während Transaktionen vor unkommissionierten Datenänderungen geschützt werden, indem Sie eine der folgenden Optionen verwenden:You can minimizeing locking contention while protecting transactions from dirty reads of uncommitted data modifications by using either of the following options:

  • Die Isolationsebene, wobei die Datenbankoption festgelegt ist.
  • Isolationsstufe

Weitere Informationen zu Isolationsstufen finden Sie unter SET TRANSACTION ISOLATION LEVEL.

Note

Wenn Sie Fehlermeldung 601 erhalten, wenn angegeben wird, beheben Sie sie wie ein Deadlock-Fehler (Fehlermeldung 1205), und wiederholen Sie die Anweisung.

REPEATABLEREAD

Gibt an, dass eine Überprüfung mit der gleichen Sperrsemantik wie eine Transaktion ausgeführt wird, die auf Isolationsebene ausgeführt wird. Weitere Informationen zu Isolationsstufen finden Sie unter SET TRANSACTION ISOLATION LEVEL.

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 werden Zeilensperren nur dann verwendet, wenn mit anderen Tabellenhinweisen kombiniert wird, die Sperren erfordern, wie z. B. und . 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 . 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 ausgeführt wird. Weitere Informationen zu Isolationsstufen finden Sie unter SET TRANSACTION ISOLATION LEVEL.

SNAPSHOT

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

Auf die speicheroptimierte Tabelle wird mit der Isolationsstufe zugegriffen. 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 OUTER 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 -Anweisung eine freigegebene Sperre abrufen. Bei Angabe von wird die gemeinsame Sperre auf die gesamte Tabelle statt auf Zeilen- oder Seitenebene angewendet. Wird zusätzlich angegeben, wird die Tabellensperre bis zum Transaktionsende aufrechterhalten.

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

Bei Verwendung mit dem OPENROWSET-Massenrowsetanbieter zum Importieren von Daten in eine Tabelle ermöglicht 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. erstellt Updatesperren für Lesevorgänge nur auf Zeilen- oder Seitenebene. Wenn mit kombiniert wird oder aus einem anderen Grund eine Sperre auf Tabellenebene erstellt wird, wird stattdessen eine exklusive Sperre (X) erstellt.

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

XLOCK

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

Remarks

Tabellenhinweise werden ignoriert, wenn der Abfrageplan nicht auf die Tabelle zugreift. Dies kann durch den Optimierer verursacht werden, der überhaupt nicht auf die Tabelle zugreift, oder weil stattdessen auf eine indizierte Ansicht zugegriffen wird. Im letzteren Fall kann der Zugriff auf eine indizierte Ansicht mithilfe des Abfragehinweiss verhindert werden.

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. Außerdem führt SQL Server die entsprechenden Konsistenzprüfungen für sperren aus.

Lockhinweise , und , die Sperren auf Zeilenebene abrufen, können Sperren auf Indexschlüsseln anstelle der tatsächlichen Datenzeilen platzieren. Wenn z. B. eine Tabelle einen nicht gruppierten Index aufweist und eine -Anweisung, die einen Sperrhinweis verwendet, von einem verdeckten Index behandelt wird, wird eine Sperre für den Indexschlüssel im abgedeckten Index und nicht für die Datenzeile in der Basistabelle abgerufen.

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 -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 nicht, wenn auf sie zugegriffen wird.

SQL Server lässt nicht mehr als einen Tabellenhinweis aus jeder der folgenden Gruppen für jede Tabelle in der FROM-Klausel zu:

  • Granularitätshinweise: , , , , oder .
  • Isolationsstufenhinweise: , , , , .

Gefilterte Indexhinweise

Ein gefilterter Index kann als Tabellenhinweis verwendet werden, bewirkt jedoch, dass der Abfrageoptimierer Fehler 8622 generiert, wenn er nicht alle Zeilen abdeckt, die die Abfrage auswählt. Es folgt ein Beispiel für einen ungültigen gefilterten Indexhinweis. Im Beispiel wird der gefilterte Index erstellt und dann als Indexhinweis für eine -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 keinen Indexhinweis, wenn die Optionen nicht über die erforderlichen Werte für gefilterte Indizes verfügen. Weitere Informationen finden Sie unter CREATE INDEX.

Verwenden Sie 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. Die automatische Verwendung einer indizierten Ansicht durch den Abfrageoptimierer wird nur in bestimmten Editionen von SQL Server unterstützt. Azure SQL-Datenbank und Azure SQL Managed Instance unterstützen auch die automatische Verwendung von indizierten Ansichten, ohne den hinweis NOEXPAND anzugeben.

Weitere Informationen finden Sie unter Handbuch zur Architektur der Abfrageverarbeitung.

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

Damit der Abfrageoptimierer jedoch indizierte Ansichten für den Abgleich in Betracht ziehen kann, oder eine indizierte Ansicht verwenden, auf die mit dem Hinweis verwiesen wird, müssen die folgenden Optionen auf festgelegt werden.

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

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

Außerdem muss die Option auf festgelegt werden.

Damit der Abfrageoptimierer einen Index für eine indizierte Sicht verwendet, geben Sie die Option 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 Ansicht in einer Abfrage zu erzwingen, in der die Ansicht nicht direkt in der FROM-Klausel angegeben wird. 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 nur automatisch Statistiken für eine indizierte Ansicht, 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 verwendet der Datenbank-Engine Ansichtsstatistiken, die automatisch oder manuell erstellt wurden, wenn die Abfrage direkt auf die Ansicht verweist und der NOEXPAND-Hinweis verwendet wird.

Verwenden eines Tabellenhinweises als Abfragehinweis

Tabellenhinweise können auch mithilfe der -Klausel 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.

Permissions

Die , und Hinweise erfordern Berechtigungen für die Tabelle.

Examples

A. Verwenden des TABLOCK-Hinweises zum Angeben einer Sperrmethode

Das folgende Beispiel spezifiziert, dass eine geteilte Sperre in der Tabelle der AdventureWorks2025-Datenbank übernommen und bis zum Ende der Anweisung gehalten 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

Das folgende Beispiel verwendet den Hinweis, ohne einen Index anzugeben, um den Abfrageoptimierer dazu zu zwingen, eine Indexsuchoperation auf der Tabelle in der AdventureWorks2025-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 -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

Das folgende Beispiel verwendet den Hinweis, um den Abfrageoptimierer dazu zu zwingen, eine Scanoperation auf der Tabelle in der AdventureWorks2025-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);

Verwandte Inhalte

  • Last updated on