Ausführungsplan vs STATISTICS IO-Reihenfolge

Die grafischen Ausführungspläne von SQL Server werden von rechts nach links und von oben nach unten gelesen. Gibt es eine sinnvolle Reihenfolge für die Ausgabe von SET STATISTICS IO ON?

Die folgende Abfrage:

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;

Erzeugt diesen Plan:

Und diese STATISTICS IOAusgabe:

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.

Also wiederhole ich: Was gibt es? Gibt es eine sinnvolle Reihenfolge für die STATISTICS IOAusgabe oder wird eine beliebige Reihenfolge verwendet?

Mein anfängliches Herumspielen mit verschiedenen Abfragen ließ überhaupt kein Muster erkennen, aber bei genauerer Betrachtung scheint es für Serienpläne vorhersehbar zu sein. Ich landete bei KB314648, das @AustinZellner erwähnt:

Jede SQL Server-Verbindung verfügt über eine zugeordnete Prozessstatusstruktur (Process Status Structure, PSS), die verbindungsspezifische Statusinformationen verwaltet. Jede eindeutige Serverprozess-ID (SPID) in der Sysprocesses-Systemtabelle stellt eine andere PSS dar, und die Informationen in der virtuellen Sysprocesses-Tabelle sind eine "Sicht" auf diese Statusinformationen.

Und der Abschnitt, der für Ihre Frage relevant ist:

Wenn STATISTICS IO für eine Verbindung aktiviert ist, weist SQL Server während der Abfrageausführung ein Array zu, um die E / A-Informationen auf Tabellenbasis zu verfolgen. Während SQL Server die Abfrage verarbeitet, zeichnet er jede logische Anforderung für eine Seite im entsprechenden Tabelleneintrag in diesem Array auf und gibt an, ob diese logische E / A-Anforderung zu einer physischen E / A geführt hat. SQL Server gibt die Informationen am Ende der Abfrage in der Fehlermeldung 3615 zurück.

Das beobachtete Verhalten deutet darauf hin, dass Einträge in der Reihenfolge des Generierens der E / A in das Array eingegeben werden. Dies ist im Wesentlichen das Ergebnis von GetNext () für einen physischen Operator. Der letzte Eintrag in der Statistikausgabe ist die erste Tabelle, die zur Aufzeichnung einer E / A geführt hat, der erste Eintrag ist die letzte Tabelle. Ich würde spekulieren, dass die Reihenfolge für parallele Pläne nicht vorhersehbar ist (oder weniger), da es keine Garantie dafür gibt, welche parallele Aufgabe zuerst geplant wird.

Sieht für mich so aus, als wäre es die umgekehrte Reihenfolge des Lesezugriffs auf Daten im Plan. Ihr Plan liest zuerst aus der Product-Tabelle, um die Hash-Tabelle (Worktable) zu erstellen. Dann liest es aus SalesOrderHeader und bildet SalesOrderDetail, indem es sie mit dem Merge-Join-Operator kombiniert. Die Worktable wird dann vom letzten gelesen, um die ursprünglichen Produktzeilen mit denen aus dem Merge-Join zu vergleichen. Dies ist genau die umgekehrte Reihenfolge, in der sie in Ihrer Statistikausgabe aufgeführt sind.

Mir ist jedoch keine Dokumentation bekannt, die dies spezifizieren würde. Wenn Sie sicher sein möchten, in welcher Reihenfolge der Tabellenzugriff erfolgt ist, lesen Sie den Ausführungsplan.

Ich dachte immer, es hätte einen Auftrag, als ich mehr programmiert als administriert habe. Ich habe ein paar Hinrichtungspläne durchgesehen und meine Überzeugungen überprüft.

Folgendes sehe ich:

In einer mehrstufigen Abfrage (wie bei vielen unserer gespeicherten Prozeduren) spiegelt die Reihenfolge die physische Reihenfolge wider, in der die Abfragen ausgeführt werden.

Für eine bestimmte Abfrage sieht es so aus, als ob die Statistik-E / A den Ausführungsplan widerspiegeln, indem Statistiken beginnend von rechts nach links gemeldet werden

Vielleicht ist dies eher eine Beobachtung als irgendetwas anderes.

Ich denke also, dass die Ergebnisse der Statistik viel mehr Aufschluss darüber geben, was zur Laufzeit tatsächlich passiert, da dies die Notwendigkeit berücksichtigt und beeinflusst, von der Festplatte anstatt vom Cache zu lesen, und auch von den Berechtigungen des Kontos beeinflusst wird dass die Abfrage unter ausgeführt wird. Die Position der Tabelle in der Statistikrendite wird dann von anderen Faktoren beeinflusst, als sie vom Profiler berücksichtigt werden.

Hier ist ein KB-Artikel, der Einblicke und einige Beispiele bietet: http://support.microsoft.com/kb/314648