Нужна помощь в понимании статистики ввода-вывода

Question

У меня есть запрос с очень дорогой операцией INDEX SEEK в плане выполнения.Чтобы отследить причину, я включил IO STATISTICS и запустил ее.В проблемном разделе он дал следующую статистику:

Таблица '# TempStudents_Enrollment2 _________________________________________________________________ 000000004D5F'.Сканирование счетчик 0, логическое чтение 60, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица «Рабочий стол».Сканирование счетчик 0, логическое чтение 0, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица '# TempRace2 ________________________________________________________________________________ 000000004D58'.Сканирование 1, логическое чтение 1, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица «Рабочий стол».Сканирование 0, логическое чтение 0, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица 'RefRace'.Сканирование 120, логическое чтение 240, физическое чтение 1, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица 'RefFedEnctyRaceCatg'.Сканирование 18, логическое чтение 36, физическое чтение 2, чтение с опережением 0, логическое чтение с 0, физическое чтение с 0, чтение с опережением 0.

Таблица '# 43B0BA0F'.Сканирование 1, логическое чтение 60, физическое чтение 0, чтение с опережением 0, логическое чтение с бита 0, физическое чтение с бита 0, чтение с опережением чтения 0 *

Таблица '# 42BC95D6'.Сканирование 1, логическое чтение 60, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с чтения 0 0.

Таблица '# 41C8719D'.Сканирование 1, логическое чтение 60, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица '# 40D44D64'.Сканирование 1, логическое чтение 60, физическое чтение 0, чтение с опережением 0, логическое чтение с боба 0, физическое чтение с бита 0, чтение с опережением чтения 0 *

Таблица '# LEA2 _____________________________________________________________________________________ 000000004D56'.Сканирование 1, логическое чтение 60, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица '# 39332B9C'.Сканирование 1, логическое чтение 60, физическое чтение 0, чтение с опережением 0, логическое чтение с боба 0, физическое чтение с боба 0, чтение с опережением, чтение 0.

Таблица '# School2 __________________________________________________________________________________ 000000004D57'.Сканирование 1, логическое чтение 29164, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением чтения 0.

Таблица '#GenderKey ________________________________________________________________________________ 000000004D5A'.Сканирование 1, логические операции чтения 29164, физические операции чтения 0, операции чтения с опережением 0, логические операции чтения 0, физические операции чтения 0, математические операции чтения 0 0.

Таблица '#LangAcqKey _______________________________________________________________________________ 000000004D5B'.Сканирование 1, логические операции чтения 29164, физические операции чтения 0, операции чтения с опережением 0, логические операции чтения 0, физические операции чтения 0, математические операции чтения 0. 0

Таблица '#TransferCatKey ___________________________________________________________________________ 000000004D5C'.Сканирование 1, логические операции чтения 29164, физические операции чтения 0, операции чтения с опережением 0, логические операции чтения 0, физические операции чтения 0, математические операции чтения 0. 0. 1034 *

Таблица '#ResCatKey ________________________________________________________________________________ 000000004D5D'.Сканирование 1, логическое чтение 29164,физическое чтение 0, чтение впереди 0, lob логическое чтение 0, lob физическое читает 0, лобовое чтение читает 0. 0. 1036 *

Таблица 'RPT_SnapShot_1_4_StuPgm_Denorm. сканирование число 2344954, логическое чтение 4992518, физическое чтение 16, чтение впереди 8, lob логическое чтение 0, lob физическое читает 0, лобовое чтение читает 0.

Таблица «# 3FE0292B». Количество сканирований 1, логическое чтение 2344954, физическое чтение 0, чтение с опережением читает 0, логический элемент читает 0, lob физический читает 0, lob упреждающее чтение читает 0.

Таблица 'RPT_SnapShot_1_4_StuEnrlmt_Denorm. Сканирование 20, логическое чтение 87679, физическое чтение 0, чтение с опережением 87425, lob логическое чтение 0, lob физическое чтение 0, чтение опережающего чтения 0.

Таблица '#GradeKey _________________________________________________________________________________ 000000004D59. Сканирование 1, логическое чтение 1, физическое чтение 0, чтение впереди 0, lob логическое чтение 0, lob физическое читает 0, лобовое чтение читает 0.

Что мне следует искать здесь, когда я хочу улучшить производительность? Строка с более чем 2 миллионами для счета сканирования показалась мне подозрительной, но я действительно не знаю. Кто-нибудь видит здесь что-нибудь, что я должен рассмотреть более подробно?

Answer 1

Источник: MS SQL Server 2008 R2 Unleashed

Количество сканирований Значение счетчика сканирования показывает, сколько раз к соответствующей таблице обращались во время выполнения запроса. Внешняя таблица соединения с вложенным циклом обычно имеет число сканирований 1. Число сканирований для внутренних таблиц обычно отражает количество раз, которое внутренние поиск таблицы, который обычно совпадает с количеством подходящих строк во внешнем Таблица. Количество логических чтений для внутренней таблицы равно умноженному числу сканирований по количеству страниц на поиск для каждого сканирования. Обратите внимание, что счетчик сканирования для внутреннего таблица иногда может быть только 1 для вложенного объединения, если SQL Server копирует необходимые строки из внутренней таблицы в рабочую таблицу в кэш-памяти и читает из рабочей таблицы для последующие итерации (например, если используется операция Table Spool). Количество сканирования для хеш-соединений и объединений слиянием обычно 1 для обеих таблиц, участвующих в объединении, но логические чтения для этих типов соединений обычно значительно выше.

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

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

Чтение впереди Значение чтения с опережением показывает количество страниц, прочитанных в кеш-память с использованием механизм опережающего чтения при обработке запроса. Страницы, прочитанные в упреждающем прочтении механизм не обязательно будет использоваться запросом. Когда страница прочитана в упреждающем чтении механизм обращается к запросу, он считается логическим чтением, но не физическим. Механизм опережающего чтения можно рассматривать как оптимистическую форму физического ввода-вывода, чтение страниц в кеш-память, которая, как ожидается, потребуется запросу до запроса нуждается в них. При сканировании таблицы или индекса карта распределения индекса таблицы страницы (IAM) просматриваются, чтобы определить, какие экстенты принадлежат объекту. Степень состоит из восьми страниц данных. Восемь страниц в экстенте читаются с одного чтения, и экстенты читаются в том порядке, в котором они хранятся на диске. Если таблица распределена по несколько файлов, механизм упреждающего чтения пытается параллельно читать до восьми файлов в время вместо последовательного чтения из файлов .read.

Answer 2

Вы уже выполнили " установить статистику ввода-вывода на ". В меню «Запрос» включите « Включить фактический план выполнения » и «Включить статистику клиента». Запустите ваш запрос / процедуру. На вкладке " messages " найдите наибольшее число " Logical reads ", запомните эту таблицу. На вкладке «План выполнения» найдите таблицу, которую вы нашли в предыдущем шаге (как правило, имеет самый высокий процент затрат, связанный с планом). Если это « Сканирование » (сканирование таблицы или сканирование индекса), вам не хватает соответствующего индекса, или у соответствующего индекса нет хорошей статистики. Если это «Поиск», то искомые строки разбросаны по блокам. Вы должны объединить их физически, создав индекс CLUSTERED для столбца, который вы ищете. Это ОЧЕНЬ эффективный метод. Мало кто знает о кластерных индексах. Потратьте некоторое время на изучение их. По умолчанию сервер Sql создает первичный ключ, который кластеризован, и большинство людей оставляют его таким. И во многих случаях это может привести к снижению производительности. Вам нужен кластеризованный индекс, чтобы физически сгруппировать строки по столбцам, на которых вы строите кластерный индекс. Вы можете иметь только один кластерный индекс на таблицу. Кластерный индекс не должен быть уникальным, не должен быть PK, может состоять из нескольких столбцов. Вы можете переписать запрос, например, замена существует с IN и наоборот, или замена существует с объединением таблиц. Не существует «самого быстрого» метода соединения. Если будет один, все другие типы будут автоматически преобразованы в этот самый быстрый. Это зависит от данных, доступных индексов, количества оперативной памяти и т. Д.

Всегда измеряйте, не предполагайте. Измерение - это только правда. Сколько вам удалось сократить логическое чтение, тем больше вам удалось оптимизировать запрос. Другими оптимизациями будет уровень базы данных, выполняемый DBA (кэш-память, параллельные процессы, система хранения, анализ событий ожидания и т. Д.)

Answer 3

Кажется, там довольно дорогой индекс сканирование : Table 'RPT_SnapShot_1_4_StuPgm_Denorm'. Scan count 2344954, logical reads 4992518.

Answer 4

Единственная фигура, о которой стоит беспокоиться - это «Логические чтения». Физические чтения будут зависеть от того, сколько данных кешируется в данный момент, что может меняться при каждом выполнении запроса.

Количество сканирований иногда говорит , но на самом деле не стоит фокусироваться.

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