План выполнения в сравнении с STATISTICS IO order

Графические планы выполнения SQL Server читаются справа налево и сверху вниз. Есть ли значимый порядок в выводе SET STATISTICS IO ON?

Следующий запрос:

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;

Создает этот план:

И этот STATISTICS IOвывод:

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.

Итак, повторюсь: что дает? Есть ли значимый порядок STATISTICS IOвывода или какой-то произвольный порядок используется?

Моя первоначальная игра с различными запросами вообще не предполагала какого-либо паттерна, но при более пристальном внимании это кажется предсказуемым для серийных планов. Я закончил на KB314648, который @AustinZellner упоминает:

Каждое соединение с SQL Server имеет связанную структуру состояния процесса (PSS), которая поддерживает информацию о состоянии конкретного соединения. Каждый уникальный ID процесса сервера (SPID) в системной таблице sysprocesses представляет отдельную PSS, а информация в виртуальной таблице sysprocesses представляет собой «представление» этой информации о состоянии.

И раздел, соответствующий вашему вопросу:

Если для соединения включен ввод-вывод STATISTICS, во время выполнения запроса SQL Server выделяет массив для отслеживания информации ввода-вывода для каждой таблицы. Когда SQL Server обрабатывает запрос, он записывает каждый логический запрос для страницы в соответствующую запись таблицы в этом массиве вместе с тем, привел ли этот логический запрос ввода-вывода к физическому вводу-выводу. SQL Server возвращает информацию в конце запроса в сообщении об ошибке 3615.

Наблюдаемое поведение предполагает, что в массив вносятся записи в порядке генерации ввода-вывода, по сути, результат GetNext () для физического оператора. Последняя запись в выводе статистики - это первая таблица, в которой был записан ввод-вывод, первая запись - последняя таблица. Я бы предположил, что порядок для параллельных планов не предсказуем (или менее), поскольку нет никакой гарантии относительно того, какая параллельная задача будет запланирована первой.

Похоже, это противоположный порядок доступа к данным в плане. Ваш план сначала будет считан из таблицы Product, чтобы построить хеш-таблицу (рабочий стол). Затем он читает из SalesOrderHeader и формирует SalesOrderDetail, объединяя их с оператором объединения слиянием. Затем рабочий стол читается последним, чтобы хеш-сопоставление исходных строк продукта со строками из объединения слиянием. Это прямо противоположный порядок, в котором они перечислены в вашей статистике.

Тем не менее, я не знаю ни одной документации, которая бы указала это. Если вы хотите быть уверены, в каком порядке произошел доступ к таблице, ознакомьтесь с планом выполнения.

Я всегда думал, что у него был заказ, когда я занимался больше программированием, чем администрированием. Я проверил несколько планов выполнения и дважды проверил свои убеждения.

Вот что я вижу:

В многошаговом запросе (например, во многих наших хранимых процедурах) порядок отражает физический порядок, в котором выполняются запросы.

Для конкретного запроса, похоже, статистика ввода-вывода отражает план выполнения, сообщая статистику, начиная с справа и работая слева

Возможно, это больше наблюдение, чем все остальное.

Поэтому я думаю, что результаты статистики дают гораздо больше информации о том, что на самом деле происходит во время выполнения, так как будут учитывать и будут зависеть от необходимости чтения с диска вместо кэша, а также будут зависеть от разрешений учетной записи. что запрос выполняется под. Положение таблицы в результатах статистики зависит от других факторов, которые не учитывались профилировщиком.

Вот статья в КБ, которая дает представление и несколько примеров: http://support.microsoft.com/kb/314648