Как проверить, насколько сервер использует индексы? | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Backend-разработчик на PHP
-9%
Алгоритмы и структуры данных
-9%
Team Lead
-6%
Архитектура и шаблоны проектирования Разработчик IoT
-13%
C# Developer. Professional
-9%
HTML/CSS
-11%
C# ASP.NET Core разработчик
-5%
Kotlin Backend Developer
-8%
iOS Developer. Professional
-8%
Java Developer. Professional JavaScript Developer. Professional Базы данных Android Developer. Professional Framework Laravel Cloud Solution Architecture Highload Architect Reverse-Engineering. Professional Vue.js разработчик Agile Project Manager VOIP инженер Scala-разработчик Супер-практикум по использованию и настройке GIT Symfony Framework Java Developer. Basic Unity Game Developer. Professional Супер-интенсив Azure
Инфраструктура
Экспресс-курс «IaC Ansible»
-10%
Administrator Linux.Basic
-10%
Мониторинг и логирование: Zabbix, Prometheus, ELK
-10%
Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes»
-30%
Administrator Linux. Professional
-6%
Дизайн сетей ЦОД
-13%
NoSQL Основы Windows Server MS SQL Server Developer Инфраструктурная платформа на основе Kubernetes Cloud Solution Architecture Highload Architect Разработчик голосовых ассистентов и чат-ботов VOIP инженер Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Супер-интенсив "Tarantool"
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Как проверить, насколько сервер использует индексы?

SQL_Deep_30.1_site-5020-d9bd6d.png

В этом нам поможет замечательная DMV sys.dm_db_index_usage_stats. В ней есть информация о том, сколько раз используется индекс при поиске (user_seeks, user_scans и user_lookups), и о том, сколько раз нужно обновить данные в индексе при изменении данных в таблице (user_updates).

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

declare @dbid int
select @dbid = db_id()
select (cast((user_seeks + user_scans + user_lookups) as float) / case user_updates when 0 then 1.0 else cast(user_updates as float) end) * 100 as [%]
    , (user_seeks + user_scans + user_lookups) AS total_usage
    , objectname=object_name(s.object_id), s.object_id
    , indexname=i.name, i.index_id
    , user_seeks, user_scans, user_lookups, user_updates
    , last_user_seek, last_user_scan, last_user_update
    , last_system_seek, last_system_scan, last_system_update
    , 'DROP INDEX ' + i.name + ' ON ' + object_name(s.object_id) as [Command], i.*
from sys.dm_db_index_usage_stats s,
    sys.indexes i
where database_id = @dbid 
and objectproperty(s.object_id,'IsUserTable') = 1
and i.object_id = s.object_id
and i.index_id = s.index_id
AND i.name IS NOT NULL
AND i.is_primary_key = 0        --исключаем Primary Key
AND i.is_unique_constraint = 0  --исключаем Constraints
--and object_name(s.object_id) = 'MyBigTable'
order by [%] asc

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

Например, у меня в практике был индекс, по которому считался большой и важный отчёт. Он считался редко, 1 раз в месяц. Я, используя статистику, нашла этот огромный индекс вообще без использования, всё проверила, убедилась, что никто его не использует, и удалила.

А потом, настало время расчёта того самого отчёта. И сразу стало понятно, чей был этот огромный индекс. Благо, это был отчётный сервер, на котором индекс можно было создать, не повлияв на клиентов, но просыпаться для этого ночью всё же пришлось.

Поэтому лучше перепроверьте несколько раз, что ваш индекс точно не используется. И перед удалением возьмите таймаут хотя бы на 2 недели, вдруг что-нибудь выявится.

Появились вопросы? Пишите их в комментариях!

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться