2009-05-04 3 views
17

Ich bin dabei zu versuchen, eine Abfrage zu optimieren, die historische Daten nachschlägt. Ich benutze den Abfrage-Analysator, um den Ausführungsplan nachzuschlagen, und habe festgestellt, dass der Großteil meiner Abfragekosten auf etwas basiert, das "Lesezeichen-Suche" genannt wird. Ich habe diesen Knoten nie zuvor in einem Ausführungsplan gesehen und weiß nicht, was es bedeutet.Was ist eine Lesezeichen-Suche in Sql Server?

Ist das eine gute Sache oder eine schlechte Sache in einer Abfrage?

Antwort

28

Eine Lesezeichen-Suche ist der Prozess zum Suchen der tatsächlichen Daten in der SQL-Tabelle basierend auf einem Eintrag in einem nicht gruppierten Index.

Wenn Sie in einem nicht gruppierten Index nach einem Wert suchen und Ihre Abfrage mehr Felder als den Indexblattknoten (alle Indexfelder sowie alle möglichen INCLUDE-Spalten) benötigt, muss SQL Server ausgeführt werden rufen Sie die tatsächliche (n) Datenseite (n) ab - dies wird als Lesezeichen-Suche bezeichnet.

In einigen Fällen ist das wirklich der einzige Weg zu gehen - nur wenn Ihre Abfrage nur ein weiteres Feld (nicht eine ganze Reihe von em) erfordern würde, könnte es eine gute Idee sein, dieses Feld in die nicht enthalten gruppierter Index. In diesem Fall würde der Knoten auf Blattebene des nicht gruppierten Index alle Felder enthalten, die zur Erfüllung Ihrer Abfrage benötigt werden (ein "deckender" Index), und somit wäre eine Lesezeichen-Suche nicht mehr erforderlich.

Marc

+2

Einverstanden. Wenn ein großer Prozentsatz der Tabelle zurückgegeben wird, kann es besser sein, nur einen Tabellenscan durchzuführen. Wenn die Statistik jedoch schlecht ist, erhalten Sie möglicherweise einen Plan, der stattdessen die Lesezeichen-Suche durchführt. Es gibt ein ziemlich anständiges kostenloses Ebook auf Ausführungsplänen bei redgate - http://www.red-gate.com/specials/Grant.htm – ahains

+1

Yup, die Red Gate Seite war viele tolle SQL Server Sachen verfügbar - viele davon für kostenlos auch! –

3

Es ist ein NESTED LOOP die einen nicht gruppierten Index mit dem Tisch verbindet sich auf einem Zeilenzeiger.

geschieht für die Abfragen wie folgt aus:

SELECT col1 
FROM table 
WHERE col2 BETWEEN 1 AND 10 

, wenn Sie einen Index auf col2 haben.

Der Index col2 enthält Zeiger auf die indizierten Zeilen.

, um so den Wert von col1 abzurufen, wobei der Motor den Index auf col2 für die Schlüsselwerte 1-10, und für jeden Index Blatt scannen muss, auf die Tabelle beziehen sich die Zeiger in die enthaltene Verwendung Blatt, um den Wert von col1 herauszufinden.

This article weist darauf hin, dass ein Bookmark Lookup ist SQL Server 2000 's Begriff, der durch NESTED LOOP ersetzt ist zwischen dem Index und die Tabelle in SQL Server 2005 und über

+0

CLUSTERED KEY LOOKUP ist die Lesezeichen-Suche, AFAIK. –

+0

Es mag ein bisschen verwirrend sein, es als NESTED LOOP zu bezeichnen, es ist nicht wirklich verwandt mit dem NESTED LOOP Join Typ, richtig? Ich denke, Sie sprechen nur konzeptionell? – ahains

+0

Jeder Datensatz in einer Tabelle hat einen physischen Zeiger, mit dem auf diesen Datensatz zugegriffen werden kann. Ein nicht gruppierter Index ist tatsächlich eine andere Tabelle. Wenn Sie eine SELECT * FROM-Tabelle where col1 BETWEEN a UND b machen, gibt es tatsächlich einen versteckten Join: SELECT * FROM col1_index JOIN-Tabelle ON table.rowid = col1_index WHERE col1_index.col1 ZWISCHEN a UND b. Dieser Join kann NESTED LOOP und sogar HASH sein (wenn zwei Indizes zusammengefügt werden). – Quassnoi

2

Von MSDN in Bezug auf Bookmark Lookups:

Der Bookmark Lookup Operator verwendet ein Lesezeichen (Zeilen-ID oder Clustering-Schlüssel) zu suchen Sie die entsprechende Zeile in der Tabelle oder Clustered-Index. Die Spalte des Arguments enthält das Lesezeichen-Label , das zum Suchen der Zeile in der Tabelle oder des Clustered-Index verwendet wird. Das Argument Spalte enthält auch den Namen der Tabelle oder gruppierten Index, in dem die Zeile nachgeschlagen wird.Wenn die WITH PREFETCH -Klausel in der Argument-Spalte angezeigt wird, der Abfrageprozessor bestimmt hat, dass es optimal ist, asynchron Prefetching zu verwenden (read-ahead), wenn oben Lesezeichen in der Tabelle oder gruppierten Index suchen.

Verwandte Themen