J'ai quelques personnes à remercier pour une mise à jour récente de SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) et Greg Gonzalez (blog | @SQLsensei), bien sûr, pour la R&D et pour creuser dans le code et le trier. Mais aussi à Paul White (blog | @SQL_kiwi) pour sa persévérance à nous aider à valider les correctifs.
Le problème découvert par Paul est que SQL Server 2008+ perturbe les estimations de cardinalité sur certaines requêtes lorsque des recherches de clé ou de RID sont impliquées. Je laisserai l'explication plus approfondie au billet de blog de Paul et au bogue qu'il a déposé sur Connect, mais pour faire court, nous prenions ces estimations déformées, les croyions et les extrapolions pour vous montrer de "meilleures" informations. Malheureusement, comme l'explique Paul, nous avons été dupés.
Paul affiche la requête suivante sur une copie d'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 produit le plan suivant, tel que Paul l'a décrit :
Dans Plan Explorer, nous avons essayé d'être utiles en multipliant le nombre estimé de lignes (arrondi à 17) par le nombre d'exécutions (45), et nous avons obtenu 765 :
Pour la plupart des opérateurs, cette approche produit les bonnes données, mais en raison de ce bogue dans SQL Server, elle n'est pas correcte pour les recherches de clé/RID. Nous nous sommes ajustés en conséquence et avons publié le correctif approprié dans la version 7.2.42.0 (téléchargez-le maintenant !). Le plan graphique affiche désormais correctement le nombre de lignes correct pour les deux estimations :
Et réel :
Je vais répéter l'avertissement de Paul :Attention aux mauvaises estimations de cardinalité lorsqu'un prédicat est appliqué dans le cadre d'une recherche.
Il y avait des problèmes plus complexes causés par ces estimations trompeuses, que nous avons également abordés. Je vais bloguer sur quelques-uns d'entre eux dans un post de suivi - pour ce post, je voulais juste démontrer que nous avons rapidement résolu le problème spécifique que Paul a mis en évidence dans son post.
