Ви можете використовувати один з цих двох запитів, щоб побачити загальне логічне читання та загальне фізичне читання.
SELECT DB_NAME(st.dbid) Db,
OBJECT_NAME(st.objectid, st.dbid) Prc,
qs.execution_count,
qs.total_logical_reads,
qs.total_physical_reads,
qs.statement_start_offset,
qs.statement_end_offset,
st.text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st;
SELECT DB_NAME(database_id) Db,
OBJECT_NAME(object_id, database_id) Prc,
execution_count,
total_logical_reads,
total_physical_reads
FROM sys.dm_exec_procedure_stats ps;
Перший розбиває це на висловлювання, другий вважає за всю процедуру.
Фізичні читання - це зчитування з диска, логічні - проти пам'яті. Ви можете використовувати це для того, щоб визначити, які процедури чи заяви найдорожчі у вашій системі, і спробувати їх налаштувати.
Майте на увазі, що хоча логічні зчитування значно дешевші, ніж фізичні читання, вони все ще дорогі, тому зменшення їх кількості (наприклад, додавши відповідний індекс) може змусити ваші запити працювати набагато швидше.
У версії DMV є багато додаткових стовпців, які також можуть вам бути цікавими.
Як індекс допомагає зменшити логічні зчитування?
У SQL Server усі дані впорядковані в блоки, розміром 8 КБ. Ці блоки називаються "сторінки".
Кожна таблиця містить "мета" сторінки, що містять інформацію про структури таблиці, а також сторінки пати. Якщо індексу немає, і ви запускаєте запит, наприклад, що SELECT * FROM tbl WHERE Id = 7SQL Server повинен шукати ту чи ці рядки у всій таблиці. Таким чином, він читається по одній сторінці по черзі, перебирає всі рядки на кожній сторінці, щоб визначити рядки, які відповідають WHEREпідпункту. Отже, якщо в таблиці потрібно зберігати 1 000 000 сторінок, для цього запиту потрібно виконати 1 000 000 логічних зчитувань.
Якщо у вас є індекс, SQL Server логічно сортує дані на сторінках і встановлює зв'язаний список між сторінками. Це дозволяє виконувати запити з a ORDER BYбез виконання дорогої операції сортування. Але важливо, що сортування, SQL Server додає до таблиці B + дерево . Дерево B + - це структура, порівнянна з індексом книги, де пошук конкретного ключового слова дозволяє мені безпосередньо перейти на сторінку, що містить ключове слово. Типова книга має лише один рівень індексу, тоді як дерево B + може мати декілька. Подумайте лише про велику книгу, де сам індекс - кілька сторінок. У такому випадку має сенс додати додатковий індексний шар, який повідомляє нам, на якій сторінці Sслід знайти індексні слова, починаючи з цього.
B + Дерева оптимізовані так, щоб вони мали якомога менше рівнів, забезпечуючи властивість, що будь-який запис у індексі можна знайти, прочитавши одну сторінку за рівнем індексу. Тому припустіть вищезазначений WHERE Id = 7запит, коли у вас індекс відсортований Id. Скажімо, індекс має 5 рівнів. Тепер, щоб знайти всі записи, що відповідають цьому запиту, я повинен прочитати одну сторінку на рівні індексу (тобто 5 сторінок). Це називається "Шукати індекс". Якщо є кілька записів, які відповідають рахунку, мені, можливо, доведеться деякий час слідувати відсортованому індексу, щоб отримати їх усі. Але припустимо, що існує лише один запис.
Отже, без виконання індексу для цього запиту було потрібно 1000 000 прочитаних, а для індексу потрібно 5 зчитування. Навіть незважаючи на те, що логічне зчитування є операцією в пам'яті, це значна істотна вартість - адже це найдорожча операція в тривіальному запиті, як вище. Таким чином, зменшення кількості логічних зчитувань, необхідних в 200 000 разів, пришвидшить ваш запит аналогічним фактором.
Так, логічне зчитування не еквівалентне скануванню таблиці, але сканування таблиці викликає набагато більше логічних зчитувань, ніж пошук індексу.
