Plan wykonania a STATYSTYKA zamówienie IO

Graficzne plany wykonania programu SQL Server odczytują od prawej do lewej i od góry do dołu. Czy generowana przez jest znacząca kolejność SET STATISTICS IO ON?

Następujące zapytanie:

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;

Generuje ten plan:

I ta STATISTICS IOwydajność:

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.

Powtarzam: co daje? Czy istnieje sensowne uporządkowanie danych STATISTICS IOwyjściowych lub czy użyto jakiegoś arbitralnego porządku?

Moja wstępna gra z różnymi zapytaniami nie sugerowała żadnego wzorca, ale po zwróceniu uwagi wydaje się przewidywalna w przypadku planów seryjnych. Skończyłem na KB314648, o którym wspomina @AustinZellner:

Każde połączenie z programem SQL Server ma powiązaną strukturę statusu procesu (PSS), która przechowuje informacje o stanie specyficzne dla połączenia. Każdy unikalny identyfikator procesu serwera (SPID) w tabeli systemowej sysprocesses reprezentuje inny PSS, a informacje w wirtualnej tabeli sysprocesses to „widok” na te informacje o stanie.

I sekcja odnosząca się do twojego pytania:

Jeśli STATYSTYKA IO jest włączona dla połączenia, SQL Server przydziela tablicę podczas wykonywania zapytania, aby śledzić informacje IO na podstawie tabeli. Gdy SQL Server przetwarza zapytanie, rejestruje każde logiczne żądanie strony w pozycji odpowiedniej tabeli w tej tablicy, wraz z tym, czy to logiczne żądanie We / Wy spowodowało fizyczne We / Wy. SQL Server zwraca informacje na końcu zapytania w komunikacie o błędzie 3615.

Obserwowane zachowanie sugeruje, że wpisy są wprowadzane do tablicy w kolejności generowania IO, zasadniczo wynik GetNext () na operatorze fizycznym. Ostatni wpis w danych statystycznych to pierwsza tabela, która spowodowała zapisanie zamówienia we / wy, pierwszy wpis to ostatnia tabela. Spekulowałbym, że kolejność równoległych planów nie jest przewidywalna (lub mniej), ponieważ nie ma gwarancji, które zadanie równoległe zostanie zaplanowane jako pierwsze.

Wydaje mi się, że jest to odwrotna kolejność dostępu do odczytu danych w planie. Twój plan najpierw przeczyta z tabeli Produkt, aby zbudować tabelę skrótów (stół roboczy). Następnie odczytuje z SalesOrderHeader i tworzy SalesOrderDetail łącząc je z operatorem łączenia scalania. Następnie odczytywany jest stół roboczy od ostatniego, aby dopasować oryginalne wiersze produktu do wierszy ze scalenia. Jest to dokładnie odwrotna kolejność, w jakiej są wymienione w wynikach statystycznych.

Nie znam jednak żadnej dokumentacji, która by to precyzowała. Jeśli chcesz się upewnić, w jakiej kolejności nastąpił dostęp do tabeli, przeczytaj plan wykonania.

Zawsze myślałem, że ma rozkaz, od samego początku, kiedy robiłem więcej programowania niż administracji. Przejrzałem kilka planów wykonania i dwukrotnie sprawdziłem swoje przekonania.

Oto co widzę:

W zapytaniu wieloetapowym (takim jak wiele naszych procedur przechowywanych) kolejność odzwierciedla fizyczną kolejność uruchamiania zapytań.

W przypadku konkretnego zapytania wygląda na to, że statystyki we / wy odzwierciedlają plan wykonania, raportując statystyki zaczynające się od prawej i pracujące po lewej

Być może jest to bardziej spostrzeżenie niż cokolwiek innego.

Myślę więc, że wyniki statystyk io dają znacznie lepszy wgląd w to, co faktycznie dzieje się w środowisku wykonawczym, ponieważ weźmie ono pod uwagę i będzie miało na nie wpływ potrzeba odczytu z dysku zamiast z pamięci podręcznej, a także pod wpływem uprawnień konta pod którym uruchomione jest zapytanie. Na pozycję tabeli w statystykach wpływają wówczas inne czynniki niż te brane pod uwagę przez profilera.

Oto artykuł KB, który daje wgląd i kilka przykładów: http://support.microsoft.com/kb/314648