Dåliga uppskattningar av kardinalitet från SSMS-planer – redux

För över tre år sedan nu skrev jag om en korrigering av Plan Explorer angående dåliga kardinalitetsberäkningar som SQL Servers Showplan XML producerade, i fallet med nyckel/RID-sökningar med ett filterpredikat i SQL Server 2008 och högre. Jag tänkte att det skulle vara intressant att se tillbaka och gå in lite mer i detalj om en av dessa planer och de iterationer som vi gick igenom för att säkerställa att vi visade korrekta mätvärden, oavsett vad Management Studio visar. Återigen, detta arbete utfördes till stor del av Brooke Philpott (@MacroMullet) och Greg Gonzalez (@SQLsensei) och med stor input från Paul White (@SQL_Kiwi).

Detta är ganska likt frågan jag presenterade i mitt tidigare inlägg, som kom från Paul (och som skulle kräva lite arbete att återskapa exakt i moderna versioner av AdventureWorks, där åtminstone transaktionsdatum har ändrats):

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';

Planen från Management Studio såg korrekt ut:

Men om du tittar närmare verkar det som att ShowPlan har drivit det uppskattade antalet avrättningar från nyckelsökningen rakt över till det uppskattade antalet rader för det slutliga utbytet:

Vid första anblicken ser det grafiska plandiagrammet i Plan Explorer ganska likt ut planen som SSMS producerar:

Nu, i processen med att utveckla Plan Explorer, har vi upptäckt flera fall där ShowPlan inte riktigt får sin matte korrekt. Det mest uppenbara exemplet är procentsatser som summerar till över 100 %; vi får det här rätt i de fall där SSMS är löjligt avstängt (jag ser detta mer sällan idag än jag brukade, men det händer fortfarande).

Ett annat fall är där, från och med SQL Server 2008, SSMS började lägga totala beräknade rader istället för rader per exekvering tillsammans med uppslagningar, men endast i fall där ett predikat skjuts till uppslagningen (som fallet i denna bugg som rapporterats av Paul, och denna nyare observation av Joey D'Antoni). I tidigare versioner av SQL Server (och med funktioner och spooler) skulle vi vanligtvis visa uppskattat antal rader som kommer från en uppslagning genom att multiplicera de uppskattade raderna per exekvering (vanligtvis 1) med det uppskattade antalet rader enligt SSMS. Men med denna förändring skulle vi räkna för mycket, eftersom operatören nu redan gör den matematiken. Så i tidigare versioner av Plan Explorer, mot 2008+, skulle du se dessa detaljer i verktygstipsen, anslutningslinjerna eller i de olika rutnäten:

(Var kommer 1 721 ifrån? 67,5 beräknade körningar x 25 4927 beräknade rader.)

Redan 2012 åtgärdade vi en del av det här problemet genom att inte utföra den här matematiska operationen längre, och enbart förlita oss på det uppskattade antal rader som kommer från nyckelsökningen. Detta var nästan korrekt, men vi förlitade oss fortfarande på det beräknade radantalet ShowPlan gav oss för det slutliga utbytet:

Vi tog snabbt upp det här problemet också, i version 7.2.42.0 (släppt på Hallowe'en 2012), och känner nu att vi tillhandahåller information som är mycket mer korrekt än Management Studio (även om vi kommer att hålla ett öga på denna bugg från Paul) :

Detta hände helt klart för länge sedan, men jag tyckte ändå att det skulle vara intressant att dela med mig av det. Vi fortsätter att göra förbättringar av Plan Explorer för att ge dig så korrekt information som möjligt, och jag kommer att dela med mig av några fler av dessa nuggets i kommande inlägg.