План виконання проти замовлення IO STATISTICS

Графічні плани виконання 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), яка підтримує інформацію про стан, пов’язану з з'єднанням. Кожен унікальний ідентифікатор процесу сервера (SPID) у системній таблиці системних процесів являє собою інший PSS, а інформація у віртуальній таблиці sysprocess являє собою "погляд" на цю інформацію про стан.

І розділ, що стосується вашого питання:

Якщо для з'єднання ввімкнено функцію IST STATISTICS, SQL Server виділяє масив під час виконання запиту для відстеження інформації IO на основі таблиці. Оскільки SQL Server обробляє запит, він записує кожен логічний запит на сторінку у відповідній таблиці запису в цьому масиві разом з тим, чи призвів цей логічний запит IO до фізичного IO. SQL Server повертає інформацію, наприкінці запиту, у повідомленні про помилку 3615.

Спостережувана поведінка говорить про те, що записи в масив вносяться в тому порядку, в якому генерується IO, по суті є результатом GetNext () на фізичному операторі. Останній запис у виведенні статистики - це перша таблиця, яка призвела до запису вводу-виводу, перша запис - остання таблиця. Я б міркував, що замовлення на паралельні плани не передбачуване (або менше), оскільки немає гарантії того, яке паралельне завдання буде заплановане першим.

Мені здається, це протилежний порядок доступу до читання даних у плані. Ваш план спочатку буде прочитаний з таблиці продуктів, щоб скласти хеш-таблицю (робочий стіл). Чим він читає від SalesOrderHeader, так і формує SalesOrderDetail, поєднуючи їх з оператором об'єднання об'єднань. Потім робочий стіл зчитується з останнього до хеш-відповідності оригінальних рядків продукту з тими, що знаходяться в об'єднанні. Це точно протилежний порядок, у якому вони вказані у ваших статистичних даних.

Однак мені не відома жодна документація, яка б це вказувала. Якщо ви хочете бути впевнені в тому, до якого доступу до таблиці замовлень сталося, прочитайте план виконання.

Я завжди вважав, що в ньому є наказ, ще з тих пір, коли я робив більше програмування, ніж адміністрація. Я пробіг кілька планів виконання та двічі перевірив свої переконання.

Ось що я бачу:

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

Для певного запиту виглядає так, що статистичний IO відображає план виконання, повідомляючи про статистику, починаючи справа і працюючи зліва

Можливо, це більше спостереження, ніж будь-що інше.

Тому я вважаю, що результати статистики io дають набагато більше розуміння того, що насправді відбувається під час виконання, оскільки це враховуватиме та впливатиме на потребу читання з диска замість кешу, а також впливатиме на дозволи доступу до облікового запису під яким виконується запит. На положення таблиці в статистиці повернення тоді впливають інші фактори, ніж ті, які вважає профайлер.

Ось стаття про kb, яка дає зрозуміти та приклади: http://support.microsoft.com/kb/314648