Plan d'exécution vs ordre STATISTIQUE IO


20

Les plans d'exécution graphique de SQL Server se lisent de droite à gauche et de haut en bas. Existe-t-il un ordre significatif pour la sortie générée par SET STATISTICS IO ON?

La requête suivante:

SET STATISTICS IO ON;

SELECT  *
FROM    Sales.SalesOrderHeader AS soh
        JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID
        JOIN Production.Product AS p ON sod.ProductID = p.ProductID;

Génère ce plan:

Plan d'exécution graphique

Et cette STATISTICS IOsortie:

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderDetail'. Scan count 1, logical reads 1246, physical reads 3, read-ahead reads 1277, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderHeader'. Scan count 1, logical reads 689, physical reads 1, read-ahead reads 685, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Product'. Scan count 1, logical reads 15, physical reads 1, read-ahead reads 14, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Alors, je réitère: qu'est-ce qui donne? Existe-t-il un ordre significatif de STATISTICS IOsortie ou un ordre arbitraire est-il utilisé?

Réponses:


9

Mon jeu initial avec diverses requêtes n'a suggéré aucun modèle, mais en y prêtant plus d'attention, il semble être prévisible pour les plans en série. Je me suis retrouvé au KB314648 dont @AustinZellner mentionne:

Chaque connexion SQL Server a une structure d'état de processus (PSS) associée qui conserve les informations d'état spécifiques à la connexion. Chaque ID de processus serveur unique (SPID) dans la table système sysprocesses représente un PSS différent et les informations dans la table virtuelle sysprocesses sont une "vue" dans ces informations d'état.

Et la section pertinente à votre question:

Si STATISTICS IO est activé pour une connexion, SQL Server alloue un tableau lors de l'exécution de la requête pour suivre les informations d'E / S table par table. Au fur et à mesure que SQL Server traite la requête, il enregistre chaque demande logique d'une page dans l'entrée de la table appropriée dans ce tableau, ainsi que si cette demande d'E / S logique a abouti à un E / S physique. SQL Server renvoie les informations, à la fin de la requête, dans le message d'erreur 3615.

Le comportement observé suggère que les entrées sont effectuées dans le tableau dans l'ordre de génération d'E / S, essentiellement le résultat de GetNext () sur un opérateur physique. La dernière entrée dans la sortie des statistiques est la première table qui a entraîné l'enregistrement d'un E / S, la première entrée est la dernière table. Je suppose que l'ordre des plans parallèles n'est pas prévisible (ou moins) car il n'y a aucune garantie quant à la tâche parallèle qui sera planifiée en premier.


5

Il me semble que c'est l'ordre inverse de l'accès en lecture des données dans le plan. Votre plan sera d'abord lu dans la table Product pour créer la table de hachage (table de travail). Qu'il lit à partir de SalesOrderHeader et forme SalesOrderDetail en les combinant avec l'opérateur de jointure de fusion. La table de travail est ensuite lue du dernier pour faire correspondre les lignes de produit d'origine avec celles de la jointure de fusion. Il s'agit de l'ordre inverse exact dans lequel ils sont répertoriés dans votre sortie de statistiques.

Cependant, je n'ai connaissance d'aucune documentation qui le préciserait. Si vous voulez être sûr de l'accès à la table des ordres, lisez le plan d'exécution.


Dans ce cas, cela se produit dans un ordre opposé, dans d'autres, c'est différent. Je soupçonne qu'aucun ordre n'est détectable sans une connaissance intime du moteur qui n'est généralement pas accessible au public.
Jeremiah Peschka

Avez-vous un exemple où il se trouve dans un ordre différent?
Sebastian Meine

SELECT * FROM Sales.SalesOrderHeader AS soh JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID LEFT JOIN Sales.SalesPerson AS sp ON soh.SalesPersonID = sp.BusinessEntityID LEFT JOIN Person.Person AS p2 ON sp.BusinessEntityID = p2 .BusinessEntityID JOIN Production.Product AS p ON sod.ProductID = p.ProductID;
Jeremiah Peschka

Tant qu'il n'y a pas de parallélisme, mon observation reste vraie. Vous pouvez exécuter votre requête avec un TOP (100), TOP (1000) et TOP (10000) pour voir les plans de série. Cependant, avec TOP (100000) ou sans TOP, vous obtenez deux plans parallèles différents et là, tous les paris semblent être désactivés.
Sebastian Meine

3

J'ai toujours pensé qu'il y avait une commande, depuis l'époque où je faisais plus de programmation que d'administration. J'ai parcouru quelques plans d'exécution et revérifié mes croyances.

Voici ce que je vois:

Dans une requête en plusieurs étapes (comme beaucoup de nos procédures stockées), l'ordre reflète l'ordre physique dans lequel les requêtes sont exécutées.

Pour une requête particulière, il semble que les statistiques d'E / S reflètent le plan d'exécution en rapportant les statistiques en commençant par la droite et en travaillant vers la gauche

C'est peut-être plus une observation qu'autre chose.


2
Ça pourrait être quelque chose là-dedans. Inverser l'ordre des tables dans SELECT COUNT(*) FROM HumanResources.EmployeeDepartmentHistory UNION ALL SELECT COUNT(*) FROM HumanResources.Employee UNION ALL SELECT COUNT(*) FROM HumanResources.Departmentinverse également la IOsortie, mais cela n'explique pas pourquoi la table de travail est indiquée en premier dans l'exemple de la question.
Martin Smith

@MartinSmith Oui, la table de travail est un joker de mon point de vue limité.
RLF

0

Je pense donc que les résultats des statistiques io donnent beaucoup plus d'informations sur ce qui se passe réellement à l'exécution, car ils prendront en compte et seront affectés par la nécessité de lire à partir du disque au lieu du cache, et seront également influencés par les autorisations du compte sous lequel la requête est exécutée. La position du tableau dans le retour des statistiques est alors influencée par d'autres facteurs que ceux pris en compte par le profileur.

Voici un article de kb qui donne un aperçu et quelques exemples: http://support.microsoft.com/kb/314648


1
La question ne concerne pas la sortie de STATISTICS IOen général. Il s'agit uniquement de l'ordre dans lequel les lectures des différentes tables sont reportées. Je ne vois rien à ce sujet dans votre lien.
Martin Smith
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.