Dåliga uppskattningar av kardinalitet kommer från SSMS-exekveringsplaner

Jag har några personer att tacka för en nyligen genomförd uppdatering av SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) och Greg Gonzalez (blogg | @SQLsensei), naturligtvis, för FoU och för att gräva i koden och reda ut den. Men också till Paul White (blogg | @SQL_kiwi) för att han var ihärdig med att hjälpa oss att validera korrigeringarna.

Problemet som Paul upptäckte är att SQL Server 2008+ förstör kardinalitetsuppskattningar på vissa frågor när nyckel- eller RID-sökningar är inblandade. Jag lämnar den djupare förklaringen till Pauls blogginlägg och felet han skickade in på Connect, men lång historia kort, vi tog dessa felaktiga uppskattningar, trodde på dem och extrapolerade dem för att visa dig "bättre" information. Tyvärr, som Paul förklarar, blev vi lurade.

Paul visar följande fråga mot en kopia av 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 ger följande plan, precis som Paul beskrev det:

I Plan Explorer försökte vi vara till hjälp genom att multiplicera det uppskattade antalet rader (avrundat till 17) med antalet körningar (45), och kom fram till 765:

För de flesta operatörer ger detta tillvägagångssätt rätt data, men på grund av denna bugg i SQL Server är det inte korrekt för nyckel/RID-sökningar. Vi har justerat för det och släppt lämplig fix i 7.2.42.0 (ladda ner den nu!). Den grafiska planen visar nu korrekt antal rader för båda uppskattade:

Och faktiskt:

Jag upprepar Pauls varning:Se upp för dåliga kardinalitetsuppskattningar när ett predikat används som en del av en uppslagning.

Det fanns några mer komplexa problem som orsakades av dessa vilseledande uppskattningar, som vi också har tagit upp. Jag kommer att blogga om några av dem i ett uppföljande inlägg – för det här inlägget ville jag bara visa att vi snabbt löste det specifika problem som Paul lyfte fram i sitt inlägg.