Dårlige kardinalitetsestimater kommer fra SSMS-udførelsesplaner

Jeg har et par mennesker at takke for en nylig opdatering til SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) og Greg Gonzalez (blog | @SQLsensei), selvfølgelig, til forskning og udvikling og for at grave i koden og ordne den. Men også til Paul White (blog | @SQL_kiwi) for vedholdende at hjælpe os med at validere rettelserne.

Problemet Paul opdagede er, at SQL Server 2008+ ødelægger kardinalitetsestimater på visse forespørgsler, når nøgle- eller RID-opslag er involveret. Jeg vil overlade den dybere forklaring til Pauls blogindlæg og fejlen, han indsendte på Connect, men lang historie kort, vi tog disse forkerte skøn, troede på dem og ekstrapolerede dem for at vise dig "bedre" information. Desværre, som Paul forklarer, blev vi narret.

Paul viser følgende forespørgsel mod en kopi af 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 giver følgende plan, ligesom Paul beskrev den:

I Plan Explorer forsøgte vi at være behjælpelige ved at gange det estimerede antal rækker (afrundet til 17) med antallet af henrettelser (45), og kom frem til 765:

For de fleste operatører giver denne tilgang de rigtige data, men på grund af denne fejl i SQL Server er den ikke korrekt til nøgle/RID opslag. Vi har justeret for det og frigivet den passende rettelse i 7.2.42.0 (download den nu!). Den grafiske plan viser nu korrekt rækkeantal for begge estimerede:

Og faktisk:

Jeg vil gentage Pauls advarsel:Pas på for dårlige kardinalitetsestimater, når et prædikat anvendes som en del af et opslag.

Der var nogle mere komplekse problemer forårsaget af disse vildledende skøn, som vi også har behandlet. Jeg vil blogge om et par af dem i et opfølgende indlæg – til dette indlæg ville jeg blot demonstrere, at vi hurtigt løste det specifikke problem, Paul fremhævede i sit indlæg.