Sql statistics io scan count описание

Простой вопрос, но я не нашел хорошего объяснения в Google. При использовании Set Statistics IO ON логическое число просмотров и сканирования предоставляется в окне сообщений студии управления. Если у меня есть:

tblExample, число сканирования 5, логическое чтение 20

Что означает число сканирования?

Ответы

Ответ 1

Из книг On Line

Количество сканирования: Число выполняемых индексов или таблиц.

логическое чтение: Количество страниц, считанных из кэша данных.

физическое чтение: Количество страниц, считанных с диска.

чтение вперед: Количество страниц, помещенных в кеш для запроса.

См. также здесь: http://technet.microsoft.com/en-us/library/ms184361.aspx

Ответ 2

Насколько "сканирование таблицы" означает, лучшее, что я могу найти, это следующее:

Счет проверки просто означает, сколько раз во время запроса обращались к таблице или индексу. Это может быть полное сканирование, частичное сканирование или просто поиск.

Другими словами, счетчик сканирования сам по себе не является достаточной информацией для продолжения. Вам нужно знать, что такое сканирование, точно, поэтому вам нужно будет посмотреть на фактический план выполнения для более подробной информации. В итоге это не очень полезная метрика сама по себе!

Дополнительно:

http://www.eggheadcafe.com/software/aspnet/32171165/set-statistics-io-scan-count-explanation.aspx

К сожалению, Количество сканирования в эти дни не очень информативно. Хм, ну, если вы видите число, подобное 19223, вероятно, доступ к таблице через объединение вложенного цикла много раз.

Было время, когда "число сканирования" просто означало "доступ к таблице раз", но это было давно, возможно, в SQL 6.5. Единственный раз, когда вы могли получить счетчик сканирования с этим определением 0 имеет такой запрос, как...

select *
from TestA1
where CompanyID = 1
and CompanyID = 2

... где SQL Server мог бы сделать вывод о том, что запрос не вернется любые строки, не обращаясь к таблице.

Ответ 3

Если продолжать собирать цитаты msdn. Тогда [1], которое повторяется в [2]:

  • " Логические чтения
    Это значение указывает общее количество обращений к страницам, необходимых для обработки запроса. Каждая страница считывается из кэша данных, независимо от того, нужно ли было принести эту страницу с диска в кеш для любого прочитанного. Это значение всегда не менее велико и обычно больше, чем значение для физических чтений. Одну и ту же страницу можно прочитать много раз (например, когда запрос вызывается из индекса), поэтому количество логических чтений для таблицы может быть больше, чем количество страниц в таблице.

  • Физические чтения
    Это значение указывает количество страниц, которые были прочитаны с диска; он всегда меньше или равен значению логических чтений. Значение коэффициента "Хэш-кеш-буфера", отображаемое в Performance Monitor, вычисляется из значений "Логическое чтение и физическое считывание" следующим образом:

  • Чтение чтения в режиме чтения
    Значение Read Ahead Reads указывает количество страниц, которые были прочитаны в кеше, с использованием механизма чтения вперед при обработке запроса. Эти страницы не обязательно используются в запросе. Если страница в конечном счете необходима, логическое чтение подсчитывается, но физическое чтение - нет. Высокое значение означает, что значение для физических чтений, вероятно, ниже, а отношение кэш-бит, вероятно, выше, чем... [усечено vgv8]

  • Количество сканирования
    Значение "Количество сканирования" указывает количество раз, к которому обращалась соответствующая таблица. Внешние таблицы вложенного соединения цикла имеют показатель сканирования 1. Для внутренних таблиц число сканирования может быть числом "через цикл", к которому была обращена эта таблица. Количество логических чтений определяется суммой подсчета сканирования, умноженной на количество страниц, к которым осуществляется доступ при каждом сканировании. Тем не менее, даже для вложенных объединений циклов граф сканирования для внутренней таблицы может отображаться как 1. SQL Server может скопировать нужные строки из внутренней таблицы в рабочую таблицу в кеше и использовать эту рабочую таблицу для доступа к фактическим строкам данных. Когда этот шаг используется в плане, его часто нет в выводе STATISTICS IO. Вы должны использовать вывод из STATISTIC TIME, а также информацию о фактическом используемом плане обработки, чтобы определить фактическую работу, связанную с выполнением запроса. Соединения хэша и объединения слияния обычно показывают количество сканирования как 1 для обеих таблиц, участвующих в объединении, но эти типы объединений могут включать в себя значительно большую память. Вы можете проверить значение memusage в sysprocesses во время выполнения запроса, но в отличие от значения физического_io, это не кумулятивный счетчик и действителен только для текущего выполняемого запроса. Как только запрос завершается, нет способа узнать, сколько памяти оно использовало.

[1]
Глава 4. Устранение неполадок производительности запросов. Мониторинг производительности запросов
Внутри Microsoft® SQL Server ™ 2005: настройка и оптимизация запросов
Кален Делани

Издатель: Microsoft Press
Паб Дата: 26 сентября 2007 г.
Печать ISBN-10: 0-7356-2196-9
Печать ISBN-13: 978-0-7356-2196-1
Страницы: 448

[2]
Мониторинг производительности запросов
Оптимизация производительности запросов
Рон Сукуп, Кален Делани
Глава 14 изнутри Microsoft SQL Server 7.0, опубликованная Microsoft Press
http://technet.microsoft.com/en-us/library/cc917719.aspx#ECAA