Holen Sie SQL Server für die Verwendung von index seek + Taste-lookup nicht gruppierte index scan, ohne MIT (FORCESEEK -)

Version: SQL Server 2008 R2

Datenbank: AdventureWorks 2008R2 von http://msftdbprodsamples.codeplex.com/releases/view/55926

Abfrage:

SELECT TOP 10
    *
FROM
    Person.Person --WITH (FORCESEEK)
WHERE
    LastName like 'Max%'
    OR EXISTS (
        SELECT
            1
        FROM
            Person.PersonPhone
        WHERE
            Person.PersonPhone.BusinessEntityID = Person.Person.BusinessEntityID
            AND Person.PersonPhone.PhoneNumber LIKE '122%'
    )
ORDER BY Person.Person.BusinessEntityID DESC


Ohne jede Abfrage, Tipp, SQL Server clustered-index-scan, das ist IO-intensiv:

Table 'PersonPhone'. Scan count 14170, logical reads 28446, physical reads 15, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Person'. Scan count 1, logical reads 2844, physical reads 3, read-ahead reads 3215, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.


Mit der WITH (FORCESEEK) Abfrage-Tipp, SQL Server entscheiden Sie sich für index seek + Taste-lookup, der wird schneller abgeschlossen und ist 500 x kinder, um die IO:

Table 'Person'. Scan count 1, logical reads 59, physical reads 22, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'PersonPhone'. Scan count 1, logical reads 2, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.


Meine Frage ist, gibt es eine Möglichkeit, um SQL Server zu verwenden, besser zu planen, ohne jede Abfrage Tip??? Das hinzufügen von Indizes vielleicht? Oder ändern von config-Parametern? Oder ist der SQL Server-Abfrageoptimierer die ahnungslosen?

Hier ist ein Juwel von http://msdn.microsoft.com/en-us/library/bb510478.aspx:

Abfrageoptimierer Regeln und schlechte Schätzung der Kardinalität kann auch dazu führen, dass der Optimierer führen Sie eine Tabelle oder einen index-scan-Vorgang vielmehr als ein index seek, wenn eine Abfrage verwendet oder WIE suchprädikat.

  • SQL Server wird automatisch parametrisiert werden einige Abfragen - ich weiß nicht, die Besonderheiten, aber es könnte sein, dass er versucht zu optimieren, der oben für jede WIE ... Werte und als solche macht einen schlechten plan Wahl für diese Besondere suchen.
  • Wenn Sie Lesen, die Frage kann man sehen, dass ohne Abfrage ein Tipp, dem query optimizer wählen Sie den plan, die erfordert, dass 500x mehr IO. Vielleicht haben Sie festgestellt, dass meine Festplatte wurde im Leerlauf und die Sehnsucht nach Arbeit? Das könnte ein guter Grund. Sowieso vorausgesetzt, Sie haben die Frage nochmal Lesen, können Sie sehen, dass ich wurde gefragt für einen Weg zu helfen, den query optimizer wählen Sie das besser zu planen, ohne Angabe von FORCESEEK.
  • Ich glaube nicht, dass der SQL-Server wird die hardware-und entscheiden, dass ein bestimmter plan ist gut, denn die hardware ist aktuell im Leerlauf - plan-Erstellung ist teuer wrt. Ressourcen - und Pläne sind oft erstellt, mit Wiederverwendung in den Sinn.
  • A, ich war sarkastisch 😛
InformationsquelleAutor sayap | 2011-05-10
  1. 4

    Hier ist eine version, die Exponate zu 'anständigen' IO-zahlen, ohne Rückgriff auf die Verwendung von FORCESEEK.
    Es ist interessant, dass diese schreckliche sucht-Abfrage führt 'besser'.

    DISCLAIMER: Dies kann eine bessere Leistung für 'Max%' und '122%', aber wie werde es erfüllen, wenn der plan wird wiederverwendet 'M%' und '%' ist eine andere Sache...

    SELECT TOP 10 *
FROM Person.Person P
INNER JOIN (
SELECT BusinessEntityID
FROM    Person.Person --WITH (FORCESEEK)
WHERE    LastName like 'Max%'    

UNION

SELECT BusinessEntityID
FROM    Person.Person --WITH (FORCESEEK)
WHERE    EXISTS (        SELECT            *        FROM        
    Person.PersonPhone        WHERE            Person.PersonPhone.BusinessEntityID = Person.Person.BusinessEntityID            AND Person.PersonPhone.PhoneNumber LIKE '122%'    )
) NOTNICE
ON NOTNICE.BusinessEntityID = P.BusinessEntityID
ORDER BY P.BusinessEntityID DESC
    • Vielen Dank, das funktioniert. Leider ist es nicht sehr "ORM-freundlich".
    • Gut, mit SQLAlchemy, es gibt keine solche Sache als "nicht-ORM-freundlich". Ich habe dies erfolgreich umgesetzt. Nochmals vielen Dank für die Antwort.
    InformationsquelleAutor Will A
Schreibe einen Kommentar