Devo ringraziare alcune persone per un recente aggiornamento a SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) e Greg Gonzalez (blog | @SQLsensei), ovviamente, per ricerca e sviluppo e per scavare nel codice e risolverlo. Ma anche a Paul White (blog | @SQL_kiwi) per essere stato persistente nell'aiutarci a convalidare le correzioni.
Il problema scoperto da Paul è che SQL Server 2008+ confonde le stime di cardinalità su determinate query quando sono coinvolte ricerche di chiavi o RID. Lascerò la spiegazione più approfondita al post sul blog di Paul e al bug che ha segnalato su Connect, ma per farla breve, stavamo prendendo queste stime travisate, credendoci ed estrapolandole per mostrarti informazioni "migliori". Sfortunatamente, come spiega Paul, siamo stati ingannati.
Paul mostra la seguente query su una copia di 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 produce il seguente piano, proprio come lo ha descritto Paul:
In Plan Explorer, abbiamo cercato di essere utili moltiplicando il numero stimato di righe (arrotondato a 17) per il numero di esecuzioni (45) e siamo arrivati a 765:
Per la maggior parte degli operatori, questo approccio fornisce i dati corretti, ma a causa di questo bug in SQL Server, non è corretto per le ricerche chiave/RID. Ci siamo adattati per questo e abbiamo rilasciato la correzione appropriata in 7.2.42.0 (scaricala ora!). Il piano grafico ora mostra correttamente i conteggi di righe corretti per entrambi i valori stimati:
E reale:
Ripeto l'avvertimento di Paul:Fai attenzione alle scarse stime di cardinalità quando un predicato viene applicato come parte di una ricerca.
C'erano alcuni problemi più complessi causati da queste stime fuorvianti, che abbiamo anche affrontato. Ne parlerò in un blog in un post di follow-up:per questo post volevo solo dimostrare che abbiamo risolto rapidamente il problema specifico che Paul ha evidenziato nel suo post.
