Tabellenhinweis (Transact-SQL)

Aktualisiert: 12. Dezember 2006

Gibt an, dass der Abfrageoptimierer mit dieser Tabelle oder Sicht und für diese SELECT-, INSERT-, UPDATE- oder DELETE-Anweisung einen Table Scan, einen oder mehrere Indizes oder eine Sperrmethode verwendet. Der Abfrageoptimierer findet jedoch im Allgemeinen auch ohne Angabe dieser Optimierungshinweise das beste Optimierungsverfahren.

Wichtig:
Da der SQL Server 2005-Abfrageoptimierer normalerweise den besten Ausführungsplan für eine Abfrage auswählt, empfiehlt es sich, dass Hinweise, einschließlich <table_hint>, nur von erfahrenen Entwicklern und Datenbankadministratoren verwendet werden, wenn alle anderen Möglichkeiten sich als unbefriedigend erwiesen haben.

Betrifft:

DELETE

INSERT

SELECT

UPDATE

Transact-SQL-Syntaxkonventionen

Syntax

<table_hint> ::= [ NOEXPAND ] { 
    INDEX ( index_val [ ,...n ] )
  | FASTFIRSTROW 
  | HOLDLOCK 
  | NOLOCK 
  | NOWAIT
  | PAGLOCK 
  | READCOMMITTED 
  | READCOMMITTEDLOCK 
  | READPAST 
  | READUNCOMMITTED 
  | REPEATABLEREAD 
  | ROWLOCK 
  | SERIALIZABLE 
  | TABLOCK 
  | TABLOCKX 
  | UPDLOCK 
  | XLOCK 
} 

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

Argumente

• 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 in den Hinweisen.

• INDEX ( index_val [ ,... n ] )
  Gibt den Namen oder die ID der Indizes an, die der Abfrageoptimierer beim Verarbeiten der Anweisung verwenden soll. Pro Tabelle ist nur ein Indexhinweis zulässig.

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

  Die alternative INDEX = Syntax gibt einen einzigen Indexhinweis an. Sie wird nur aus Gründen der Abwärtskompatibilität unterstützt.

  Werden mehrere Indizes in einer einzigen Hinweisliste verwendet, werden Duplikate ignoriert, und die übrigen aufgeführten Indizes werden verwendet, um die Zeilen aus der Tabelle abzurufen. 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 alles abdeckt, wird eine Abrufoperation ausgeführt, nachdem die SQL Server 2005-Datenbankmodul alle indizierten Spalten abgerufen hat.

  Hinweis:
  Wenn ein Indexhinweis, der auf mehrere Indizes verweist, in der Faktentabelle einer Sternverknüpfung 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, müssen Sie die Identitiätsspalte auslassen, es sei denn, die Identitätsspalte ist die letzte Spalte in der Tabelle. Weitere Informationen finden Sie unter Auslassen eines Datenfeldes mithilfe einer Formatdatei. Wenn eine Identitätsspalte erfolgreich ausgelassen wird, weist der Abfrageoptimierer der Identitätsspalte in den importierten Tabellenzeilen automatisch eindeutige Werte zu.

  Ein Beispiel für die Verwendung dieses Hinweises in einer INSERT ... SELECT * FROM OPENROWSET(BULK...)-Anweisung finden Sie unter Beibehalten von Identitätswerten beim Massenimport von Daten.

  Weitere Informationen zum Überprüfen des Identitätswertes 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 anstatt 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.

• FASTFIRSTROW
  Entspricht OPTION (FAST 1). Weitere Informationen finden Sie in der Beschreibung von FAST in der OPTION-Klausel unter SELECT.

• HOLDLOCK
  Entspricht der Option SERIALIZABLE. Weitere Informationen finden Sie unter SERIALIZABLE weiter unten in diesem Thema. 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 Anweisungs definiert ist, in der auch HOLDLOCK verwendet wird. HOLDLOCK kann in einer SELECT-Anweisung mit der Option FOR BROWSE nicht verwendet werden.

• 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. In der Standardeinstellung überprüft INSERT die Einschränkungen CHECK und FOREIGN KEY. Wenn für einen Massenimportvorgang IGNORE_CONSTRAINTS angegeben ist, müssen diese Einschränkungen für eine Zieltabelle von INSERT ignoriert werden. Beachten Sie, dass Sie die Einschränkungen UNIQUE, PRIMARY KEY oder NOT NULL nicht deaktivieren können.

  Die Deaktivierung der Einschränkungen CHECK und FOREIGN KEY kann z. B. gewünscht sein, 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 (Cleanup) der Daten verwenden.

  Wenn die Einschränkungen CHECK und FOREIGN KEY ignoriert werden, wird jede ignorierte Einschränkung in der Tabelle nach dem Vorgang jedoch in der Katalogsicht sys.check_constraints oder sys.foreign_keys als is_not_trusted markiert. Irgendwann wird es notwendig 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 von keinen Triggern abhängig ist und Leistungsmaximierung ein wichtiger Faktor ist.

• NOLOCK
  Entspricht der Option READUNCOMMITTED. Weitere Informationen finden Sie unter READUNCOMMITTED weiter unten in diesem Thema.

• NOWAIT
  IWeist die SQL Server 2005-Datenbankmodul 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.

• 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. Wird das Argument in Transaktionen angegeben, die auf der SNAPSHOT-Isolationsstufe ausgeführt werden, werden Seitensperren nur dann verwendet, wenn PAGLOCK mit anderen Tabellenhinweisen kombiniert ist, die Sperren erfordern, wie beispielsweise 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_COMITTED_SNAPSHOT auf OFF festgelegt wurde, fordert die Datenbankmodul beim Lesen der Daten gemeinsame Sperren an und hebt diese Sperren nach Abschluss des Lesevorgangs wieder auf. Wenn die Datenbankoption READ_COMMITTED_SNAPSHOT auf ON festgelegt wurde, fordert die Datenbankmodul keine Sperren an und verwendet die Zeilenversionsverwaltung. Weitere Informationen zu Isolationsstufen finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

• READCOMMITTEDLOCK
  Gibt an, dass Lesevorgänge den Regeln für die Isolationsstufe READ COMMITTED entsprechen, indem Sperren verwendet werden. Die Datenbankmodul fordert beim Lesen der Daten gemeinsame 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 finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

• READPAST
  Gibt an, dass Datenbankmodul keine Zeilen liest, die durch andere Transaktionen gesperrt wurden. In den meisten Fällen gilt dies auch für Seiten. Anstatt den aktuellen Vorgang zu blockieren, lässt die Datenbankmodul die Zeilen oder Seiten aus, bis die Sperren aufgehoben werden. READPAST kann nur in Transaktionen angegeben werden, die mit den Isolationsstufen READ COMMITTED oder REPEATABLE READ arbeiten. Wird das Argument in Transaktionen angegeben, die auf der SNAPSHOT-Isolationsstufe ausgeführt werden, muss READPAST mit anderen Tabellenhinweisen kombiniert werden, die Sperren erfordern, wie beispielsweise UPDLOCK und HOLDLOCK. Wenn READPAST angegeben wird, werden Sperren sowohl auf der Zeilenebene als auch auf der Seitenebene ausgelassen. READPAST kann für jede Tabelle, auf die in einer UPDATE- oder DELETE-Anweisung verwiesen wird, und für jede Tabelle, auf die in einer FROM-Klausel verwiesen wird, angegeben werden. Wenn Sie den READPAST-Sperrhinweis in einer UPDATE-Anweisung angeben, wird er nur angewendet, wenn Daten gelesen werden, um die Datensätze zu identifizieren, die aktualisiert werden müssen; dabei spielt es keine Rolle, wo in der Anweisung READPAST angegeben wird. READPAST kann nicht für Tabellen in der INTO-Klausel einer INSERT-Anweisung angegeben werden.

  Lesevorgänge, die READPAST verwenden, führen nicht zu Blockierungen. Aktualisierungs- oder Löschoperationen, die READPAST verwenden, können beim Lesen von Fremdschlüsseln oder indizierten Sichten oder beim Ändern sekundärer Indizes zu Blockierungen führen.

  Angenommen, Tabelle T1 enthält eine einzelne ganzzahlige Spalte mit den Werten 1, 2, 3, 4, 5. Falls Transaktion A den Wert von 3 in 8 ändert, der Commit jedoch noch nicht ausgeführt wurde, ergibt SELECT * FROM T1 (READPAST) die Werte 1, 2, 4, 5. READPAST wird hauptsächlich verwendet, um beim Implementieren einer Arbeitswarteschlange, die eine SQL Server-Tabelle verwendet, Sperrkonflikte zu reduzieren. Ein Warteschlangenlesevorgang, der READPAST verwendet, lässt durch andere Transaktionen gesperrte Warteschlangeneinträge aus und liest den nächsten verfügbaren Warteschlangeneintrag, ohne warten zu müssen, bis andere Transaktionen ihre Sperren aufheben.

• READUNCOMMITTED
  Gibt an, dass Dirty Reads zulässig sind. Es werden keine gemeinsamen Sperren angefordert, um andere Transaktionen daran zu hinden, von der aktuellen Transaktion gelesene Daten zu ändern, und exklusive Sperren, die von anderen Transaktionen verwendet wurden, hindern die aktuelle Transaktion nicht daran, die gesperrten Daten zu lesen. 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 für die Transaktion auftreten oder Benutzern Daten angezeigt werden, für die nie ein Commit ausgeführt wurde.

  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 gleichzeitigen Abfragen, auch solche mit READUNCOMMITTED- oder NOLOCK-Hinweisen, werden beim Versuch, eine Sch-S-Sperre zu errichten, gesperrt. Umgekehrt blockiert eine Abfrage, die eine Sch-S-Sperre aufrechterhält, eine gleichzeitige Transaktion, die versucht, eine Sch-M-Sperre zu errichten. Weitere Informationen zum Sperrverhalten finden Sie unter Kompatibilität von Sperren (Datenbankmodul).

  READUNCOMMITTED und NOLOCK können nicht für Tabellen angegeben werden, die durch Einfüge-, Aktualisierungs- oder Löschvorgä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 Microsoft 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.

  In SQL Server 2005 können Sie Konflikte zwischen Sperren minimieren und zugleich Transaktionen vor Dirty Reads von Datenänderungen, für die kein Commit ausgeführt wurde, mit einer der folgenden Methoden schützen:

  • Verwendung der READ COMMITTED-Isolationsstufe bei Festlegen der Datenbankoption READ_COMMITTED_SNAPSHOT auf ON.
  • Verwendung der SNAPSHOT-Isolationsstufe.

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

  Hinweis:
  Haben Sie READUNCOMMITTED angegeben und erhalten die Fehlermeldung 601, lösen Sie den Fehler auf wie einen Deadlockfehler (1205), 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 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. Wird das Argument in Transaktionen angegeben, die auf der SNAPSHOT-Isolationsstufe ausgeführt werden, werden Zeilensperren nur dann verwendet, wenn ROWLOCK mit anderen Tabellenhinweisen kombiniert ist, die Sperren erfordern, wie beispielsweise UPDLOCK und HOLDLOCK.

• SERIALIZABLE
  Entspricht der Option HOLDLOCK. Verstärkt die Einschränkung von gemeinsamen Sperren, indem sie aufrechterhalten werden, bis eine Transaktion abgeschlossen ist (anstatt die gemeinsame 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 Sperrsemantik wie eine Transaktion durchgeführt, die auf der Isolationsstufe SERIALIZABLE ausgeführt wird. Weitere Informationen zu Isolationsstufen finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

• TABLOCK
  Gibt an, dass für die Tabelle eine Sperre verwendet wird, die bis zum Anweisungsende aufrechterhalten wird. Wenn Daten gelesen werden, wird eine gemeinsame Sperre verwendet. Wenn Daten geändert werden, wird eine exklusive Sperre verwendet. Wird zusätzlich HOLDLOCK angegeben, wird eine gemeinsame Tabellensperre bis zum Transaktionsende aufrechterhalten.

  Wenn der TABLOCK-Hinweis mit dem OPENROWSET BULK-Rowsetanbieter verwendet wird, um Daten in eine Tabelle zu importieren, die keine Indizes aufweist, ermöglicht er mehreren Clients das gleichzeitige Laden von Daten in die Zieltabelle mit optimierter Protokollierung und Sperrung.

• TABLOCKX
  Gibt an, dass für die Tabelle eine exklusive Sperre verwendet wird, bis die Transaktion abgeschlossen ist.

• UPDLOCK
  Gibt an, dass Aktualisierungssperren zu verwenden und aufrechtzuerhalten sind, bis die Transaktion abgeschlossen ist.

• XLOCK
  Gibt an, dass exklusive Sperren zu verwenden und aufrechtzuerhalten sind, bis die Transaktion abgeschlossen ist. Wenn die exklusiven Sperren mit ROWLOCK, PAGLOCK oder TABLOCK angegeben werden, werden sie auf die entsprechende Ebene der Granularität angewendet.

Hinweise

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.

Die Verwendung von Kommas zwischen Tabellenhinweisen ist optional, sie wird jedoch empfohlen. Die Trennung von Hinweisen durch Leerzeichen anstelle von Kommas wird aus Gründen der Abwärtskompatibilität unterstützt.

In SQL Server 2005 werden bis auf einige Ausnahmen 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.

Die folgenden Tabellenhinweise sind mit und ohne WITH-Schlüsselwort zulässig: NOLOCK, READUNCOMMITTED, UPDLOCK, REPEATABLEREAD, SERIALIZABLE, READCOMMITTED, FASTFIRSTROW, TABLOCK, TABLOCKX, PAGLOCK, ROWLOCK, NOWAIT, READPAST, XLOCK und NOEXPAND. Wenn diese Tabellenhinweise ohne das WITH-Schlüsselwort angegeben werden, sollten die Hinweise allein angegeben werden. Beispiel:

FROM t (FASTFIRSTROW)

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

FROM t WITH (FASTFIRSTROW, INDEX(myindex))

Die Einschränkungen gelten, wenn die Hinweise in Abfragen für Datenbanken verwendet werden, die den Kompatibilitätsgrad 90 aufweisen.

In SQL Server 2005 werden alle Sperrhinweise an alle Tabellen und Sichten weitergeleitet, 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 der Zeilenebene anfordern, platzieren Sperren ggf. auf Indexschlüsseln und nicht auf den eigentlichen Datenzeilen. 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, anstatt 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 angewandt. Das heißt, die Tabellenhinweise werden nicht weitergeleitet. Angenommen, für eine Tabelle in der Abfrage wird der Tabellenhinweis NOLOCK 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, ROWLOCK, TABLOCK oder TABLOCKX.
• Isolationsstufenhinweise: HOLDLOCK, NOLOCK, READCOMMITTED, REPEATABLEREAD, SERIALIZABLE.

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 Funktion heißt Übereinstimmung indizierter Sichten und wird nur in der Enterprise und in der Developer Edition von SQL Server 2005 unterstützt.

Damit der Optimierer indizierte Sichten für den Abgleich oder die Verwendung einer indizierten Sicht, auf die mit dem NOEXPAND-Hinweis verwiesen wird, berücksichtigt, müssen die folgenden SET-Optionen auf ON festgelegt werden:

ANSI_NULLS	ANSI_WARNINGS	CONCAT_NULL_YIELDS_NULL
ANSI_PADDING	ARITHABORT1	QUOTED_IDENTIFIERS

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 Optimierer einen Index für eine indizierte Sicht verwendet, geben Sie die Option NOEXPAND an. Dieser Hinweis kann nur verwendet werden, wenn die Sicht ebenfalls in der Abfrage benannt wird. SQL Server 2005 stellt keinen Hinweis zur Verfügung, um die Verwendung einer bestimmten indizierten Sicht in einer Abfrage, die die Sicht nicht direkt in der FROM-Klausel benennt, zu erzwingen. Der Abfrageoptimierer zieht jedoch die Verwendung indizierter Sichten in Erwägung, selbst wenn in der Abfrage nicht direkt auf sie verwiesen wird.

Weitere Informationen finden Sie unter Auflösen von Indizes für Sichten.

Berechtigungen

Für die KEEPIDENTITY, IGNORE_CONSTRAINTS- und IGNORE_TRIGGERS-Hinweise werden ALTER-Berechtigungen für die Tabelle benötigt.

Beispiele

Im folgenden Beispiel wird angegeben, dass eine gemeinsame Sperre auf der Tabelle Production.Product platziert und bis zum Ende der UPDATE-Anweisung aufrechterhalten wird.

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

Siehe auch

Verweis

OPENROWSET (Transact-SQL)
Hinweise (Transact-SQL)

Andere Ressourcen

Sperrhinweise
Sichtauflösung

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf

Version	Verlauf
12. Dezember 2006	Geänderter Inhalt: Der Typ der vom TABLOCK-Hinweis verwendeten Sperre wurde verdeutlicht. Die Beschreibung des IGNORE_CONSTRAINTS-Hinweises wurde überarbeitet, um anzugeben, dass dieser zum Ignorieren der Einschränkungen CHECK und FOREIGN KEY führt.
14. April 2006	Neuer Inhalt: Informationen zum Verwenden von PAGLOCK, READPAST und ROWLOCK in Transaktionen, die auf der SNAPSHOT-Isolationsstufe ausgeführt werden, wurden hinzugefügt.
05. Dezember 2005	Geänderter Inhalt: Aktualisierte Informationen zum READUNCOMMITTED-Sperrhinweis.