Plano de execução x ordem STATISTICS IO

Os planos de execução gráfica do SQL Server são lidos da direita para a esquerda e de cima para baixo. Existe uma ordem significativa para a saída gerada por SET STATISTICS IO ON?

A seguinte 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;

Gera este plano:

E esta STATISTICS IOsaída:

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.

Então, reitero: o que dá? Existe uma ordem significativa para a STATISTICS IOsaída ou alguma ordem arbitrária é usada?

Minha brincadeira inicial com várias consultas não sugeria nenhum padrão, mas, prestando mais atenção, parece previsível para planos em série. Acabei no KB314648, que o @AustinZellner menciona:

Cada conexão do SQL Server tem uma estrutura de status do processo (PSS) associada que mantém informações de estado específicas da conexão. Cada identificação de processo do servidor (SPID) exclusiva na tabela do sistema sysprocesses representa um PSS diferente e as informações na tabela virtual sysprocesses são uma "exibição" dessas informações de status.

E a seção relevante para sua pergunta:

Se o STATISTICS IO estiver habilitado para uma conexão, o SQL Server alocará uma matriz durante a execução da consulta para rastrear informações de IO por tabela. À medida que o SQL Server processa a consulta, ele registra cada solicitação lógica de uma página na entrada da tabela apropriada nessa matriz, além de saber se essa solicitação de E / S lógica resultou em uma E / S física. SQL Server retorna as informações, no final da consulta, na mensagem de erro 3615.

O comportamento observado sugere que as entradas sejam feitas na matriz na ordem em que as E / S são geradas, essencialmente o resultado de GetNext () em um operador físico. A última entrada na saída de estatísticas é a primeira tabela que resultou em um IO sendo registrado, a primeira entrada é a última tabela. Eu especularia que a ordem dos planos paralelos não é previsível (ou menos), pois não há garantia de qual tarefa paralela será agendada primeiro.

Parece-me que é a ordem oposta de acesso de leitura de dados no plano. Seu plano será lido primeiro na tabela Produto para criar a tabela de hash (tabela de trabalho). Depois, leia SalesOrderHeader e o formulário SalesOrderDetail, combinando-os com o operador de junção de mesclagem. A tabela de trabalho é lida desde a última vez para combinar com hash as linhas originais do produto com as da junção de mesclagem. Essa é a ordem exatamente oposta na qual eles estão listados na saída de estatísticas.

No entanto, não conheço nenhuma documentação que especifique isso. Se você quiser ter certeza de que ordem o acesso à tabela ocorreu, leia o plano de execução.

Eu sempre pensei que tinha um pedido, quando eu fazia mais programação do que administração. Executei alguns planos de execução e verifiquei minhas crenças.

Aqui está o que eu vejo:

Em uma consulta de várias etapas (como muitos de nossos procedimentos armazenados), a ordem reflete a ordem física na qual as consultas são executadas.

Para uma consulta específica, parece que as estatísticas de veiculação refletem o plano de execução relatando estatísticas começando da direita e trabalhando à esquerda

Talvez isso seja mais uma observação do que qualquer outra coisa.

Portanto, acho que os resultados das estatísticas io fornecem muito mais informações sobre o que realmente está acontecendo no tempo de execução, pois isso levará em consideração e será afetado pela necessidade de ler do disco em vez do cache, além de ser influenciado pelas permissões da conta em que a consulta está sendo executada. A posição da tabela no retorno estatístico é influenciada por outros fatores além daqueles considerados pelo criador de perfil.

Aqui está um artigo da kb que fornece informações e alguns exemplos: http://support.microsoft.com/kb/314648