Dårlige kardinalitetsestimater fra SSMS-planer

For over tre år siden nu, skrev jeg om en rettelse til Plan Explorer vedrørende dårlige kardinalitetsestimater, som SQL Servers Showplan XML producerede, i tilfælde af nøgle/RID-opslag med et filterprædikat i SQL Server 2008 og nyere. Jeg tænkte, at det ville være interessant at se tilbage og gå lidt mere i detaljer om en af disse planer og de gentagelser, vi gik igennem for at sikre, at vi viste korrekte målinger, uanset hvad Management Studio viser. Igen blev dette arbejde stort set udført af Brooke Philpott (@MacroMullet) og Greg Gonzalez (@SQLsensei) og med stor input fra Paul White (@SQL_Kiwi).

Dette er ret lig den forespørgsel, jeg præsenterede i mit tidligere indlæg, som kom fra Paul (og som ville kræve noget arbejde at gengive nøjagtigt i moderne versioner af AdventureWorks, hvor i det mindste transaktionsdatoer har ændret sig):

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 fra Management Studio så korrekt nok ud:

Men hvis du ser nærmere efter, ser det ud til, at ShowPlan har skubbet det estimerede antal henrettelser fra nøgleopslaget direkte over til det estimerede antal rækker for den endelige udveksling:

Ved første øjekast ligner det grafiske plandiagram i Plan Explorer ret meget om den plan, som SSMS producerer:

Nu, i processen med at udvikle Plan Explorer, har vi opdaget flere tilfælde, hvor ShowPlan ikke helt får sin matematik korrekt. Det mest oplagte eksempel er procenter, der summerer til over 100 %; vi får dette rigtigt i tilfælde, hvor SSMS er latterligt slukket (jeg ser det sjældnere i dag, end jeg plejede, men det sker stadig).

Et andet tilfælde er, hvor SSMS, startende i SQL Server 2008, begyndte at sætte samlede estimerede rækker i stedet for rækker pr. udførelse sammen med opslag, men kun i tilfælde, hvor et prædikat er skubbet til opslag (såsom tilfældet i denne fejl rapporteret af Paul, og denne nyere observation af Joey D'Antoni). I tidligere versioner af SQL Server (og med funktioner og spools) vil vi typisk vise estimerede rækkeantal, der kommer ud af et opslag, ved at gange de estimerede rækker pr. udførelse (normalt 1) med det estimerede antal rækker ifølge SSMS. Men med denne ændring ville vi tælle for meget, da operatøren nu allerede laver den matematik. Så i tidligere versioner af Plan Explorer, mod 2008+, ville du se disse detaljer i værktøjstip, forbindelseslinjer eller i de forskellige gitter:

(Hvor kommer 1.721 fra? 67,5 estimerede henrettelser x 25.4927 estimerede rækker.)

Tilbage i 2012 løste vi en del af dette problem ved ikke at udføre denne matematiske operation længere og udelukkende stole på det anslåede antal rækker, der kommer ud af nøgleopslaget. Dette var næsten korrekt, men vi stolede stadig på det anslåede antal rækker, ShowPlan gav os til den endelige udveksling:

Vi løste også hurtigt dette problem i version 7.2.42.0 (udgivet på Hallowe'en 2012), og føler nu, at vi leverer information, der er meget mere nøjagtig end Management Studio (selvom vi vil holde øje med denne fejl fra Paul) :

Dette er tydeligvis sket for lang tid siden, men jeg syntes stadig, det ville være interessant at dele. Vi fortsætter med at forbedre Plan Explorer for at give dig den mest nøjagtige information som muligt, og jeg vil dele et par flere af disse guldkorn i kommende indlæg.

Dårlige kardinalitetsestimater fra SSMS-planer – redux