Ich habe ein paar Leuten zu danken für ein kürzliches Update von SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) und Greg Gonzalez (Blog | @SQLsensei) natürlich für die Forschung und Entwicklung und dafür, dass sie sich mit dem Code beschäftigt und ihn sortiert haben. Aber auch Paul White (Blog | @SQL_kiwi) dafür, dass er uns beharrlich dabei geholfen hat, die Fixes zu validieren.
Das Problem, das Paul entdeckte, war, dass SQL Server 2008+ Kardinalitätsschätzungen bei bestimmten Abfragen durcheinander brachte, wenn es um Schlüssel- oder RID-Lookups ging. Ich überlasse die tiefere Erklärung Pauls Blogpost und dem Fehler, den er auf Connect gemeldet hat, aber um es kurz zu machen, wir haben diese falsch dargestellten Schätzungen genommen, ihnen geglaubt und sie extrapoliert, um Ihnen „bessere“ Informationen zu zeigen. Leider wurden wir, wie Paul erklärt, hinters Licht geführt.
Paul zeigt die folgende Abfrage für eine Kopie von AdventureWorks 2005.
SELECT
th.ProductID,
th.TransactionID,
th.TransactionDate
FROM Production.TransactionHistory AS th
WHERE
th.ProductID = 1
AND th.TransactionDate BETWEEN '20030901' AND '20031231'; Management Studio ergibt den folgenden Plan, genau wie Paul ihn beschrieben hat:
Im Plan Explorer haben wir versucht, hilfreich zu sein, indem wir die geschätzte Anzahl der Zeilen (gerundet auf 17) mit der Anzahl der Ausführungen (45) multipliziert haben, und kamen auf 765:
Für die meisten Operatoren liefert dieser Ansatz die richtigen Daten, aber aufgrund dieses Fehlers in SQL Server ist er für Schlüssel-/RID-Lookups nicht korrekt. Wir haben uns darauf eingestellt und den entsprechenden Fix in 7.2.42.0 veröffentlicht (jetzt herunterladen!). Der grafische Plan zeigt nun die korrekten Zeilenzahlen für beide Schätzungen an:
Und tatsächlich:
Ich wiederhole Pauls Warnung:Achten Sie auf schlechte Kardinalitätsschätzungen, wenn ein Prädikat als Teil einer Suche angewendet wird.
Es gab einige komplexere Probleme, die durch diese irreführenden Schätzungen verursacht wurden, die wir ebenfalls angesprochen haben. Ich werde über einige davon in einem Folgebeitrag bloggen – für diesen Beitrag wollte ich nur zeigen, dass wir das spezifische Problem, das Paul in seinem Beitrag hervorgehoben hat, schnell gelöst haben.
