Présentation
La requête SQL décrit le résultat attendu, pas la manière d'obtenir le résultat. L'ensemble des étapes spécifiques que le serveur doit suivre pour renvoyer le résultat s'appelle le plan d'exécution de la requête. Le plan est construit par l'optimiseur. La sélection d'un plan affecte la vitesse d'exécution, ce qui en fait l'un des éléments les plus importants de l'analyse des problèmes de performances des requêtes.
Le plan d'exécution comprend des opérateurs et leurs propriétés qui sont interdépendants sous la forme de l'arborescence. Chaque opérateur est responsable d'une opération logique ou physique distincte. Ensemble, ils garantissent le résultat décrit dans le texte de la requête. A l'intérieur de l'arborescence, les opérateurs sont représentés par les objets de classe dans la mémoire de SQL Server. Les utilisateurs du serveur (c'est-à-dire vous et moi) voient la description générée au format XML avec un schéma spécifique, qui est affiché graphiquement par l'environnement SQL Server Management Studio (SSMS).
Il existe de nombreux opérateurs de plans différents et encore plus de propriétés. De plus, de nouveaux apparaissent de temps en temps. Cet article n'ose pas décrire toute la variété possible d'opérateurs. Au lieu de cela, je voudrais partager les ajouts les plus intéressants à ce sujet et rappeler certains éléments anciens mais utiles.
Version serveur
Parfois, vous pouvez trouver des demandes pour la version du serveur sur les forums, même si le plan de requête est fourni dans le bon format (XML). Au lieu de cela, vous pouvez gagner du temps et ouvrir le plan d'exécution au format XML. Et le premier élément décrivant le plan vous montrera la version du serveur dans la propriété Build.
Cette méthode ne permet pas de récupérer toutes les informations sur l'édition du serveur, mais dans la plupart des cas, cela suffit pour comprendre de quoi on a affaire.
Nombre de lignes du tableau
La deuxième question fréquente est "Combien de lignes votre tableau contient-il ?". Ces informations peuvent également être récupérées depuis le plan de requête (à partir de la version 2008 du serveur). Pour cela, nous devons sélectionner l'opérateur d'accès aux données (Scan ou Seek) d'une table en question et jeter un œil à la TableCardinality biens. Il y a une autre propriété intéressante, Taille de ligne estimée, pour la spécification de la taille de la ligne et l'évaluation approximative de la taille de la table ou de l'index (étant donné que la table n'est pas compressée).
Je voudrais noter qu'il ne s'agit pas d'un nombre réel de lignes dans une table, mais de données provenant des statistiques d'objets. Cependant, ces données constituent la base des décisions prises par l'optimiseur lors de la création d'une requête.
Contexte
Le plan de requête enregistre les paramètres SET notables pour lesquels il a été conçu. Pour afficher les paramètres, vous devez sélectionner un élément racine dans le plan et développer les Définir les options biens. Par exemple, nous pouvons savoir si le plan a été construit avec l'ARITHABORT option activée (la différence de ce paramètre conduit souvent à deux plans et situations différents avec un mauvais reniflage des paramètres).
Nombre de processeurs
Nous pouvons récupérer le nombre de processeurs disponibles pour l'optimiseur. Pour cela, nous devons ouvrir le OptimizerHardwareDependentPropertie s -> EstimatedAvailableDegreeOfParallelism paramètre dans le même élément racine et multipliez-le par 2. Si un seul processeur est disponible, il n'est pas nécessaire de multiplier.
2*2 =4, 4 processeurs sont disponibles. En effet, j'ai un processeur 4 cœurs sur mon ordinateur, et les 4 cœurs sont disponibles pour le serveur. Ces informations peuvent vous aider à détecter la machine sur laquelle le plan a été généré.
Version de l'estimateur de cardinalité
Depuis SQL Server 2014, plusieurs versions de Cardinality Estimator (RU) sont disponibles. Ce mécanisme affecte la plupart des décisions prises par l'optimiseur lors de la sélection d'un plan. Vous pouvez récupérer la version de Cardinality Estimator à partir de CardinalityEstimationModelVersion propriété de l'opérateur racine.
- 0 – SQL Server <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Temps d'exécution et temps d'attente de la requête
À partir de SQL Server 2016 SP1, le plan de requête réel contient des informations sur le temps d'exécution et le temps processeur. Pour récupérer ces données, vous devez développer le QueryTimeStats propriété dans l'élément racine et affichez les valeurs de CpuTime et ElapsedTime . Nous n'avons pas besoin d'activer la collecte du temps d'exécution ou de demander "combien de temps la requête a-t-elle été exécutée ?" plus - toutes ces informations sont incluses dans le plan.
La deuxième amélioration notable est le top 10 des attentes les plus longues lors de l'exécution des requêtes. Pour cela, nous devons développer les WaitStats propriété dans l'élément racine. Cet ajout permet d'obtenir des raisons plus précises de la lenteur d'exécution des requêtes et simplifie considérablement les diagnostics.
Types de paramètres
La Liste des paramètres La propriété, qui répertorie les paramètres utilisés dans la requête, existait depuis longtemps dans le plan. Cependant, à partir de SQL Server 2016 SP1, le Parameter Data Type La propriété a été ajoutée à la définition du paramètre. Cette propriété stocke le type de données du paramètre. Cela peut être utile pour comprendre les problèmes de conversion de type.
Nombre de lignes lues et nombre estimé de lignes à lire
Le plan d'exécution comprend deux propriétés très importantes, le nombre réel de lignes et le nombre estimé de lignes. Ces propriétés contiennent des informations sur le nombre de lignes renvoyées par l'opérateur de lecture de données, mais pas sur le nombre de lignes réellement lues. Les propriétés Nombre de lignes lues et Estimation du nombre de lignes à lire répondent à cette question et permettent de récupérer le nombre de lignes que le serveur a réellement lues ou va lire. La propriété ActualRowsRead (Number of Rows Read in SSMS) est disponible à partir de SQL Server 2012 SP3, 2014 SP2, 2016 SP1. Le EstimatedRowsRead (Estimation du nombre de lignes à lire dans SSMS) est disponible à partir de SQL Server 2016 SP1.
Statistiques IO et temps d'exécution de l'opérateur
Il existe plusieurs propriétés très utiles établies dans SQL Server 2016, 2014 SP2 et disponibles dans le plan de requête réel. Il s'agit des métriques d'E/S (si un opérateur a des E/S) - Statistiques d'E/S réelles, métriques de temps CPU et d'exécution - Statistiques de temps réel et métriques de mémoire (à partir de 2016 SP1, si un opérateur a besoin de mémoire).
Les propriétés incluent les nouvelles métriques suivantes qui peuvent être divisées en threads en cas de plan parallèle :
- ActualElapsedms
- CPUms réels
- Analyses réelles
- Lectures logiques réelles
- Lectures physiques réelles
- ActualReadAheads
- ActualLobLogicalReads
- ActualLobPhysicalReads
- ActualLobReadAhead
- InputMemoryGrant
- OutputMemoryGrant
- Obtention de mémoire utilisée
Comme vous pouvez le voir dans la liste ci-dessus, vous pouvez récupérer des informations complètes sur l'exécution d'un opérateur donné, les E/S consommées et la mémoire. Dans les dernières versions de SSMS, ces métriques sont représentées dans la fenêtre des propriétés. Si vous utilisez une ancienne version de SSMS, vous pouvez les récupérer en ouvrant le plan au format XML. À mon avis, il y a maintenant tout pour afficher les pourcentages non pas par coût estimé, mais par ressources réelles écoulées (j'ai créé une suggestion sur Connect. Donc, si vous aimez l'idée, veuillez voter pour).
Informations sur les indicateurs de trace activés
Les indicateurs de trace dans SQL Server sont des "commutateurs" spéciaux du comportement de serveur par défaut à un comportement différent. À partir de SQL Server 2014 SP2 et 2016 SP1, les informations sur les indicateurs de trace activés sont disponibles dans la propriété TraceFlags de l'élément spécifique. Il peut inclure jusqu'à 100 indicateurs activés simultanément au moment de la création de la requête.
Informations sur le déversement de données vers tempdb
Certains opérateurs de plan, par exemple, tels que Sort ou Hash Match, nécessitent de la mémoire lors de l'exécution de la requête. Cependant, le volume mémoire est calculé au moment de la compilation. Pour diverses raisons (par exemple, une évaluation incorrecte du nombre ou des lignes supposés), le volume de mémoire peut être calculé de manière incorrecte. Si moins de mémoire est allouée que nécessaire pour l'exécution, le serveur devra déverser des données sur tempdb. Cela ralentit l'exécution des requêtes. Une mise en garde concernant une telle situation a été introduite dans le serveur 2012, mais à partir de SQL Server 2012 SP3, 2014 SP2, 2016, les informations de diagnostic ont été étendues et incluent désormais le volume de données renversées et de données lues. Ainsi, vous pouvez évaluer le problème et prendre les mesures appropriées.
Conclusion
Le plan d'exécution comprend de nombreuses informations utiles, le plan de requête réel comprend encore plus d'informations et le plan de requête réel dans les dernières versions de SQL Server n'est qu'une mine d'informations utiles. Cet article n'est pas destiné à apprendre à quelqu'un à analyser des plans de requête. Au lieu de cela, j'ai considéré les propriétés du plan les plus intéressantes, y compris les nouvelles propriétés et les anciennes, mais sous-estimées. J'espère que cet article vous aidera la prochaine fois que vous aurez besoin d'analyser les performances des requêtes.
L'article a été traduit par l'équipe de Codingsight avec la permission de l'auteur.
Outil utile :
dbForge Query Builder pour SQL Server - permet aux utilisateurs de créer rapidement et facilement des requêtes SQL complexes via une interface visuelle intuitive sans écriture manuelle de code.
