Il y a plus de trois ans maintenant, j'ai publié un correctif pour Plan Explorer concernant les mauvaises estimations de cardinalité produites par Showplan XML de SQL Server, dans le cas de recherches de clé/RID avec un prédicat de filtre dans SQL Server 2008 et versions ultérieures. J'ai pensé qu'il serait intéressant de revenir en arrière et d'entrer un peu plus dans les détails de l'un de ces plans et des itérations que nous avons traversées pour nous assurer que nous affichions des métriques correctes, indépendamment de ce que Management Studio affiche. Encore une fois, ce travail a été en grande partie réalisé par Brooke Philpott (@MacroMullet) et Greg Gonzalez (@SQLsensei) et avec la grande contribution de Paul White (@SQL_Kiwi).
C'est assez similaire à la requête que j'ai présentée dans mon post précédent, qui venait de Paul (et qui demanderait du travail pour être reproduite exactement dans les versions modernes d'AdventureWorks, où à tout le moins les dates de transaction ont changé) :
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'; Le plan de Management Studio semblait assez correct :
Cependant, si vous regardez de plus près, il semble que le ShowPlan ait poussé le nombre estimé d'exécutions de la recherche de clé directement vers le nombre estimé de lignes pour l'échange final :
À première vue, le diagramme de plan graphique dans Plan Explorer ressemble assez au plan produit par SSMS :
Maintenant, dans le processus de développement de Plan Explorer, nous avons découvert plusieurs cas où ShowPlan n'obtient pas tout à fait ses calculs correctement. L'exemple le plus évident est celui des pourcentages totalisant plus de 100 % ; nous obtenons ce droit dans les cas où SSMS est ridiculement désactivé (je vois cela moins souvent aujourd'hui qu'auparavant, mais cela arrive toujours).
Un autre cas est celui où, à partir de SQL Server 2008, SSMS a commencé à mettre le nombre total de lignes estimées au lieu de lignes par exécution avec les recherches, mais uniquement dans les cas où un prédicat est poussé vers la recherche (comme dans le cas de ce bogue signalé par Paul, et cette observation plus récente de Joey D'Antoni). Dans les versions antérieures de SQL Server (et avec les fonctions et les spools), nous affichions généralement le nombre de lignes estimé provenant d'une recherche en multipliant le nombre estimé de lignes par exécution (généralement 1) par le nombre estimé de lignes selon SSMS. Mais avec ce changement, nous comptons trop, puisque l'opérateur fait déjà ce calcul. Ainsi, dans les versions antérieures de Plan Explorer, par rapport à 2008+, vous verriez ces détails dans les info-bulles, les lignes de connexion ou dans les différentes grilles :
(D'où vient 1 721 ? 67,5 exécutions estimées x 25,4927 lignes estimées.)
En 2012, nous avons résolu une partie de ce problème en n'effectuant plus cette opération mathématique et en nous appuyant uniquement sur le nombre de lignes estimé provenant de la recherche de clé. C'était presque correct, mais nous comptions toujours sur le nombre de lignes estimé que ShowPlan nous fournissait pour l'échange final :
Nous avons rapidement résolu ce problème également, dans la version 7.2.42.0 (publiée à l'Halloween 2012), et nous pensons maintenant fournir des informations beaucoup plus précises que Management Studio (bien que nous garderons un œil sur ce bogue de Paul) :
Cela s'est clairement passé il y a longtemps, mais je pensais toujours que ce serait intéressant à partager. Nous continuons d'apporter des améliorations à Plan Explorer pour vous fournir les informations les plus précises possibles, et je partagerai quelques autres de ces pépites dans les prochains articles.
