Plan wykonania a STATYSTYKA zamówienie IO

20

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:

Graficzny plan wykonania

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?

Jeremiasz Peschka
źródło

Odpowiedzi:

9

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.

Mark Storey-Smith
źródło
5

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.

Sebastian Meine
źródło
W tym przypadku następuje to w odwrotnej kolejności, w innych jest inaczej. Podejrzewam, że nie ma porządku możliwego do wykrycia bez dogłębnej znajomości silnika, który nie jest ogólnie dostępny publicznie.
Jeremiasz Peschka,
Czy masz przykład, gdzie jest w innej kolejności?
Sebastian Meine,
WYBIERZ * Z Sales.SalesOrderHeader AS soh DOŁĄCZ Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID LEFT JOIN Sales.SalesPerson AS sp ON soh.SalesPersonID = sp.BusinessEntityID LEFT JOIN Person.Person AS p2 ON sp. BusinessEntityID = p2 .BusinessEntityID DOŁĄCZ do Production.Product AS p ON sod.ProductID = p.ProductID;
Jeremiasz Peschka,
Dopóki nie występuje paralelizm, moja obserwacja jest prawdziwa. Możesz uruchomić zapytanie za pomocą TOP (100), TOP (1000) i TOP (10000), aby zobaczyć plany szeregowe. Jednak z TOP (100000) lub bez TOP otrzymujesz dwa różne równoległe plany i tam wszystkie zakłady wydają się być wyłączone.
Sebastian Meine,
3

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.

RLF
źródło
2
To może być coś w tym. Odwrócenie kolejności tabel SELECT COUNT(*) FROM HumanResources.EmployeeDepartmentHistory UNION ALL SELECT COUNT(*) FROM HumanResources.Employee UNION ALL SELECT COUNT(*) FROM HumanResources.Departmentrównież odwraca dane IOwyjściowe, ale nie wyjaśnia, dlaczego tabela robocza jest zgłaszana jako pierwsza w przykładzie w pytaniu.
Martin Smith
@MartinSmith Tak, stół roboczy jest dziką kartą z mojej ograniczonej perspektywy.
RLF,
0

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

Austin Zellner
źródło
1
Pytanie nie dotyczy STATISTICS IOogólnie wyników. Chodzi wyłącznie o kolejność zgłaszania odczytów różnych tabel. Nie widzę nic na ten temat w twoim linku.
Martin Smith