Plan d'exécution vs ordre STATISTIQUE IO

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:

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é?

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.

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.

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.

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