Piano di esecuzione vs STATISTICS IO order

Piani di esecuzione grafica di SQL Server letti da destra a sinistra e dall'alto verso il basso. C'è un ordine significativo nell'output generato da SET STATISTICS IO ON?

La seguente query:

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 questo piano:

E questo STATISTICS IOoutput:

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.

Quindi, ribadisco: cosa dà? Esiste un ordinamento significativo per l' STATISTICS IOoutput o viene utilizzato un ordine arbitrario?

Il mio primo tentativo con varie domande non suggeriva alcun modello, ma prestando maggiore attenzione sembra essere prevedibile per i piani seriali. Ho finito con KB314648 che @AustinZellner menziona:

Ogni connessione a SQL Server ha una struttura di stato del processo (PSS) associata che mantiene informazioni sullo stato specifiche della connessione. Ogni ID processo univoco server (SPID) nella tabella di sistema sysprocesses rappresenta un PSS diverso e le informazioni nella tabella virtuale sysprocesses sono una "vista" in queste informazioni sullo stato.

E la sezione pertinente alla tua domanda:

Se STATISTICS IO è abilitato per una connessione, SQL Server alloca un array durante l'esecuzione della query per tenere traccia delle informazioni IO su una tabella. Man mano che SQL Server elabora la query, registra ogni richiesta logica per una pagina nella voce della tabella appropriata in questo array, insieme al fatto che tale richiesta di I / O logico abbia portato a un IO fisico. SQL Server restituisce le informazioni, al termine della query, nel messaggio di errore 3615.

Il comportamento osservato suggerisce che le voci vengono eseguite nell'array nell'ordine in cui viene generato IO, essenzialmente il risultato di GetNext () su un operatore fisico. L'ultima voce nell'output delle statistiche è la prima tabella che ha portato alla registrazione di un IO, la prima voce è l'ultima tabella. Suppongo che l'ordine per i piani paralleli non sia prevedibile (o meno) in quanto non esiste alcuna garanzia su quale attività parallela verrà pianificata per prima.

Mi sembra che sia l'ordine opposto dei dati di accesso in lettura al piano. Il piano leggerà innanzitutto dalla tabella dei prodotti per creare la tabella hash (worktable). Di quello che legge da SalesOrderHeader e forma SalesOrderDetail combinandoli con l'operatore di unione di merge. Il piano di lavoro viene quindi letto dall'ultimo per abbinare l'hash alle righe del prodotto originale con quelle dall'unione di unione. Questo è esattamente l'opposto ordine in cui sono elencati nell'output delle statistiche.

Tuttavia, non sono a conoscenza di alcuna documentazione che lo specifichi. Se vuoi essere sicuro in quale ordine è avvenuto l'accesso alla tabella, leggi il piano di esecuzione.

Ho sempre pensato che avesse un ordine, da quando ho fatto più programmazione che amministrazione. Ho seguito alcuni piani di esecuzione e ricontrollato le mie convinzioni.

Ecco cosa vedo:

In una query in più passaggi (come molte delle nostre procedure memorizzate) l'ordine riflette l'ordine fisico in cui vengono eseguite le query.

Per una query particolare, sembra che l'IO delle statistiche rifletta il piano di esecuzione segnalando le statistiche a partire da destra e lavorando a sinistra

Forse questa è più un'osservazione che altro.

Quindi penso che i risultati delle statistiche forniranno molte più informazioni su ciò che sta effettivamente accadendo in fase di runtime, poiché terrà conto e sarà influenzato dalla necessità di leggere dal disco anziché dalla cache, e anche essere influenzato dalle autorizzazioni dell'account in cui viene eseguita la query. La posizione della tabella nel ritorno delle statistiche è quindi influenzata da fattori diversi da quelli considerati dal profiler.

Ecco un articolo di KB che fornisce informazioni dettagliate e alcuni esempi: http://support.microsoft.com/kb/314648