Qu’est-ce que l’estimation de cardinalités ? Pour faire très court, c’est l’ensemble des règles mathématiques qui permettent à SQL Server d’avoir une idée assez précise du nombre de lignes qu’il aura à traiter lors de l’exécution d’une requête. C’est avec ce calcul-là qu’il sélectionne les algorithmes de jointure, de regroupement, l’ordre et la façon d’accéder aux tables, et bien d’autres choses encore. Bien sûr, ces choix varient suivant le volume de données à traiter. On le comprend donc, c’est un sujet très important, puisqu’il impacte directement les performances de l’exécution de nos chères (parfois en IO et temps CPU !) requêtes.

Alors vous allez me dire, crevant d’impatience : « bon d’accord, mais il le sort de son chapeau magique ce calcul ? » : au risque de vous décevoir, non. Dès lors qu’on soumet une requête qui filtre une table par une colonne, ou l’utilise dans une jointure, un regroupement, alors par défaut, le moteur crée automatiquement des objets de statistique. C’est à dire qu’il va échantillonner les données des colonnes des tables participant à la requête pour évaluer la distribution des données dans les colonnes (et index) de ces tables. Fort de ces informations, il peut alors réaliser le fameux calcul. Bref, ce sont des mathématiques

L’auteur du billet en question partageait sur le fait que par défaut, SQL Server estime qu’il n’y a qu’une seule ligne dans une variable de type TABLE. Ceci s’explique par le fait que SQL Server ne maintient pas d’objet de statistique sur les variables de type TABLE (pour les curieux, il le fait néanmoins sur les tables temporaires). Quand on sait l’usage qui est fait des variables de type TABLE dans les applications, il est évident qu’il arrive rarement que ces tables ne soient en charge que d’une seule ligne; de là des performances qui ne sont pas toujours en adéquation avec le volume de données à traiter.

Voyons le comportement par défaut du moteur à l’aide de la base de données AdventureWorks2012 :

L’option de session SET STATISTICS nous permet de collecter des métriques IO, temps CPU et durée en millisecondes de la requête. Son option XML expose le plan réel de requête en plus du résultat de la requête. La sortie de ce lot est, tronquée des lectures « physiques » (i.e. sur disque et pas en RAM), et des lectures LOB, puisqu’il n’y en a pas :

Table ‘Person’. Scan count 0, logical reads 59916
Table ‘#BEF1AB90′. Scan count 1, logical reads 33

SQL Server Execution Times:
CPU time = 47 ms, elapsed time = 56 ms.

Si l’on étudie le plan de requête, voici ce que l’on trouve pour notre variable de type TABLE :

Pour voir sur quelle base le moteur a réalisé ses calculs, il suffit de survoler l’opérateur Table Scan avec le curseur de la souris :

Le moteur a donc estimé qu’il n’y qu’une seule ligne dans la variable de type TABLE, puis il a exécuté le plan de cette requête. D’une certaine manière, il nous avoue s’être un peu trompé, puisqu’il nous indique qu’en réalité, il a lu 19972 lignes.

Mais, à la lecture du résumé l’article 2952444, on voit que ce comportement a été corrigé à l’aide d’un correctif dès SQL Server 2012 SP2 et le CU3 de SQL Server 2014, ce qui fait qu’il est dans les RTM des versions suivantes de SQL Server, à ce jour SQL Server 2016 et 2017 (bientôt !) :

When you populate a table variable with many rows and then join it with other tables, the query optimizer may choose an inefficient query plan, which may lead to slow query performance.

Voyons donc ce qu’il en est : nous rejouons le même lot de requête, mais avec le drapeau de trace activé cette fois :

La sortie est :

Table ‘Workfile’. Scan count 7, logical reads 64, physical reads 0, read-ahead reads 64
Table ‘Worktable’. Scan count 0, logical reads 0
Table ‘Person’. Scan count 1, logical reads 67
Table ‘#A96F2843′. Scan count 1, logical reads 33

SQL Server Execution Times:
CPU time = 31 ms, elapsed time = 39 ms.

Le gain de temps pour une requête aussi simple n’est pas négligeable, mais c’est surtout le gain en IOs qui est très intéressant ! Voyons ce que nous dit le plan de requête :

L’ordre d’accès aux tables est le même, mais on voit bien que la façon de les traiter a changé : les jointures et agrégats sont exécutés par hachage. On note aussi les avertissements (petit point d’exclamation noir dans un triangle jaune) sur ces deux opérateurs : ils ont du accéder à TempDB pour exécuter la jointure et l’agrégat, d’où les Workfile et Worktable dans la sortie de SET STATISTICS : ce sont des structures créées à la volée dans TempDB, souvent à défaut d’index pouvant supporter la requête efficacement.

Voyons ce que nous indique l’opérateur Table Scan :

Ici on voit bien que l’estimation du nombre de lignes s’est faite correctement, et c’est donc bien cela qui a conduit le moteur à changer les algorithmes de jointure et de calcul de l’agrégat.

Pour ma part, la grande majorité des instances SQL Server que j’administre actuellement sont de version 2014, et j’ai activé ce drapeau de trace sur toutes celles-ci. En effet, l’application qui repose sur cette base de données fait souvent appel à des Tabled-Valued Parameters, qui sont des variables de type table que l’on peut passer en paramètre à une procédure stockée ou un appel à la procédure stockée système sp_executesql. Les performances générales de l’application s’en sont immédiatement ressenti positivement.

Je n’irai pas jusqu’à écrire qu’il faudrait que ce drapeau de trace soit activé sur toute les instances de production, car :

1. toutes les applications et leurs charges de travail sont différentes
2. il est toujours primordial de tester et de mesurer avant d’effectuer un quelconque changement de configuration sur une instance de production

Je vous engage vivement donc à tester pour en observer l’effet :

• Pour savoir quels sont les drapeaux de trace actifs, il suffit d’exécuter DBCC TRACESTATUS seul, ou si l’on veut être plus spécifique : DBCC TRACESTATUS (2453, -1)
• Pour désactiver un drapeau de trace, il faut exécuter : DBCC TRACEOFF ({traceFlag}, -1), soit dans le cadre de ce billet : DBCC TRACEOFF (2453, -1)

N’hésitez pas à me laisser un petit commentaire !

ElSüket.

Il existe un drapeau de trace non-documenté, n° 8666, qui permet d’ajouter au document XML qui décrit le plan de requête les statistiques utilisées par l’optimiseur pour générer le plan de requêtes.

Voyons comment l’utiliser avec une requête sur la base de données AdventureWorks2012 :

Avant toute chose, notez que ce drapeau de trace n’est pas documenté. Comme toute fonctionnalité non-documentée, on ne doit JAMAIS utiliser celui-ci sur une base de données ou une instance qui sert une charge de production. Si tel devait être le cas, je ne peux en aucun cas être tenu pour responsable des conséquences. Vous devez limiter strictement l’usage de cette instruction aux environnements de test.

Utilisons la requête suivante :

Demandons maintenant à SQL Server de générer le plan de requête estimé. Celui-ci s’obtient soit en pressant CTRL + L, soit par un clic sur l’icône suivante, présente dans la barre d’outils :

On obtiendra aussi les informations ajoutées par le drapeau de trace 8666 avec le plan d’exécution réel, que l’on obtient soit en pressant CTRL + M, soit par un clic sur l’icône, suivante présente elle aussi dans la barre d’outils :

Nous devons maintenant explorer le document XML à l’origine du plan d’exécution graphique, ce qui se fait par un simple clic droit dans une zone vierge de ce dernier :

Il nous suffit maintenant de chercher la chaîne de caractères wszStatName, et nous obtenons :

On voit clairement les détails de ce que SQL Server utilise comme métriques pour calculer le plan, notamment :

– le nom de la statistique (ici c’est la statistiques sous-jacente à l’index qui supporte la clé primaire)
– le nom de la colonne la plus à gauche dans cette statistique (wszColName)
– le nombre de lignes échantillonnées lors de la génération de la statique (m_ullSnapShotModCtr)
– le nombre de lignes présentes dans la table (m_ullRowCount)
– le seuil de recalcul automatique de la statistique (ullThreshold)

Pour cette dernière valeur, on peut d’ailleurs faire le calcul suivant :

100.0 * 24,763 / 121,317 = 20.41181367821492

Soit environ 20%. Prenons la partie décimale de ce pourcentage :

(0.41181367821492 / 100.0) * 121,317 = 499.5999999999945

Soit environ 500 lignes. Ceci vérifie bien la règle du seuil de recalcul automatique des statistiques pour les tables de plus de 8MB : 500 lignes + 20% du nombre de lignes de la table.

Bons calculs de plans de requêtes et estimations de cardinalités !

ElSüket