Plan de ejecución vs ESTADÍSTICA Orden IO

Los planes de ejecución gráfica de SQL Server se leen de derecha a izquierda y de arriba a abajo. ¿Hay un orden significativo para la salida generada por SET STATISTICS IO ON?

La siguiente consulta:

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;

Genera este plan:

Y esta STATISTICS IOsalida:

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.

Entonces, reitero: ¿qué da? ¿Existe un orden significativo para la STATISTICS IOsalida o se utiliza algún orden arbitrario?

Mi juego inicial con varias consultas no sugirió ningún patrón en absoluto, pero al prestar más atención parece ser predecible para los planes en serie. Terminé en KB314648 que @AustinZellner menciona:

Cada conexión de SQL Server tiene una estructura de estado de proceso (PSS) asociada que mantiene información de estado específica de la conexión. Cada ID de proceso de servidor único (SPID) en la tabla del sistema sysprocesses representa un PSS diferente, y la información en la tabla virtual sysprocesses es una "vista" de esta información de estado.

Y la sección relevante a su pregunta:

Si STATISTICS IO está habilitado para una conexión, SQL Server asigna una matriz durante la ejecución de la consulta para rastrear la información de IO por tabla. A medida que SQL Server procesa la consulta, registra cada solicitud lógica para una página en la entrada de la tabla apropiada en esta matriz, junto con si esa solicitud lógica de E / S resultó en una E / S física. SQL Server devuelve la información, al final de la consulta, en el mensaje de error 3615.

El comportamiento observado sugiere que las entradas se realizan en la matriz en el orden en que se genera IO, esencialmente el resultado de GetNext () en un operador físico. La última entrada en la salida de estadísticas es la primera tabla que resultó en un IO registrado, la primera entrada es la última tabla. Especularía que el pedido de planes paralelos no es predecible (o menos) ya que no hay garantía de qué tarea paralela se programará primero.

Me parece que es el orden opuesto de acceso de lectura de datos en el plan. Su plan primero se leerá en la tabla Producto para crear la tabla hash (tabla de trabajo). De lo que lee de SalesOrderHeader y forma SalesOrderDetail combinándolos con el operador de combinación de combinación. La tabla de trabajo se lee desde el último para hacer un hash-match de las filas originales del Producto con las de la combinación de combinación. Ese es exactamente el orden opuesto en el que se enumeran en su salida de estadísticas.

Sin embargo, no conozco ninguna documentación que especifique esto. Si desea estar seguro en qué orden de acceso a la tabla ocurrió, lea el plan de ejecución.

Siempre pensé que tenía una orden, desde cuando hacía más programación que administración. Revisé algunos planes de ejecución y verifiqué mis creencias.

Aquí está lo que veo:

En una consulta de varios pasos (como muchos de nuestros procedimientos almacenados) el orden refleja el orden físico en el que se ejecutan las consultas.

Para una consulta en particular, parece que las estadísticas IO reflejan el plan de ejecución al informar estadísticas que comienzan desde la derecha y trabajan hacia la izquierda

Quizás esto sea más una observación que otra cosa.

Por lo tanto, creo que los resultados de las estadísticas dan mucha más información sobre lo que realmente está sucediendo en tiempo de ejecución, ya que tendrá en cuenta y se verá afectado por la necesidad de leer desde el disco en lugar de la memoria caché, y también se verá influenciado por los permisos de la cuenta bajo el cual se ejecuta la consulta. La posición de la tabla en el retorno estadístico está influenciada por otros factores distintos a los considerados por el generador de perfiles.

Aquí hay un artículo de kb que ofrece información y algunos ejemplos: http://support.microsoft.com/kb/314648