Vor über drei Jahren habe ich einen Fix für den Plan-Explorer in Bezug auf schlechte Kardinalitätsschätzungen gepostet, die Showplan-XML von SQL Server im Fall von Schlüssel-/RID-Lookups mit einem Filterprädikat in SQL Server 2008 und höher produzierte. Ich dachte, es wäre interessant, zurückzublicken und etwas detaillierter auf einen dieser Pläne und die Iterationen einzugehen, die wir durchlaufen haben, um sicherzustellen, dass wir korrekte Metriken anzeigen, unabhängig davon, was Management Studio anzeigt. Auch diese Arbeit wurde größtenteils von Brooke Philpott (@MacroMullet) und Greg Gonzalez (@SQLsensei) und mit großartigem Input von Paul White (@SQL_Kiwi) durchgeführt.
Dies ist der Abfrage, die ich in meinem früheren Beitrag präsentiert habe, ziemlich ähnlich, die von Paul stammt (und die einige Arbeit erfordern würde, um sie in modernen Versionen von AdventureWorks genau zu reproduzieren, wo sich zumindest die Transaktionsdaten geändert haben):
SELECT
th.ProductID,
p.Name,
th.TransactionID,
th.TransactionDate
FROM Production.Product AS p
JOIN Production.TransactionHistory AS th ON
th.ProductID = p.ProductID
WHERE
p.ProductID IN (1, 2)
AND th.TransactionDate BETWEEN '20070901' AND '20071231'; Der Plan von Management Studio sah richtig genug aus:
Wenn Sie jedoch genauer hinsehen, scheint es, dass der ShowPlan die geschätzte Anzahl von Ausführungen aus der Schlüsselsuche direkt auf die geschätzte Anzahl von Zeilen für den endgültigen Austausch verschoben hat:
Auf den ersten Blick sieht das grafische Plandiagramm im Plan-Explorer dem von SSMS erstellten Plan ziemlich ähnlich:
Jetzt haben wir bei der Entwicklung von Plan Explorer mehrere Fälle entdeckt, in denen ShowPlan seine Mathematik nicht ganz richtig hinbekommt. Das offensichtlichste Beispiel sind Prozentsätze, die sich zu über 100 % summieren; wir machen das richtig in Fällen, in denen SSMS lächerlich ausgeschaltet ist (ich sehe das heute seltener als früher, aber es passiert immer noch).
Ein anderer Fall ist, dass SSMS ab SQL Server 2008 damit begann, geschätzte Gesamtzeilen anstelle von Zeilen pro Ausführung zusammen mit Suchvorgängen einzufügen, aber nur in Fällen, in denen ein Prädikat an die Suche gesendet wird (wie der Fall in diesem von Paul gemeldeten Fehler). und diese neuere Beobachtung von Joey D'Antoni). In früheren Versionen von SQL Server (und mit Funktionen und Spools) zeigten wir normalerweise geschätzte Zeilenzahlen aus einer Suche, indem wir die geschätzten Zeilen pro Ausführung (normalerweise 1) mit der geschätzten Anzahl von Zeilen gemäß SSMS multiplizierten. Aber mit dieser Änderung würden wir zu viel zählen, da der Operator diese Berechnung jetzt bereits durchführt. In früheren Versionen von Plan Explorer (gegenüber 2008+) würden Sie diese Details also in den QuickInfos, Verbindungslinien oder in den verschiedenen Rastern sehen:
(Woher kommt 1.721? 67,5 geschätzte Ausführungen x 25,4927 geschätzte Zeilen.)
Im Jahr 2012 haben wir einen Teil dieses Problems behoben, indem wir diese mathematische Operation nicht mehr durchgeführt haben und uns ausschließlich auf die geschätzte Zeilenanzahl aus der Schlüsselsuche verlassen haben. Das war fast richtig, aber wir haben uns für den endgültigen Austausch immer noch auf die geschätzte Zeilenanzahl verlassen, die ShowPlan uns zur Verfügung gestellt hat:
Wir haben dieses Problem in Version 7.2.42.0 (veröffentlicht an Halloween 2012) ebenfalls schnell behoben und haben jetzt das Gefühl, dass wir Informationen bereitstellen, die viel genauer sind als Management Studio (obwohl wir diesen Fehler von Paul im Auge behalten werden). :
Das ist eindeutig vor langer Zeit passiert, aber ich dachte immer noch, es wäre interessant, es zu teilen. Wir nehmen weiterhin Verbesserungen am Plan Explorer vor, um Ihnen möglichst genaue Informationen bereitzustellen, und ich werde einige weitere dieser Nuggets in kommenden Beiträgen teilen.
