Неиспользуемые индексы

На основании этого запроса, если я вижу небольшое количество общих чтений (очень близкое к 0 или 0, например, 1 или 2) и большое или умеренное количество пользовательских обновлений (я не смог найти вставки или удаления с этим запросом) с большое количество строк, я должен теоретически удалить индекс.

SELECT DISTINCT
    OBJECT_NAME(s.[object_id]) AS ObjectName
       , p.rows TableRows
       , i.name AS [INDEX NAME]
       , (user_seeks + user_scans + user_lookups) AS TotalReads
       , user_updates UserUpdates
FROM sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] 
        AND i.index_id = s.index_id 
    INNER JOIN sys.partitions p ON p.object_id = i.object_id
WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') = 1
       AND s.database_id = DB_ID()
       AND i.name IS NOT NULL
ORDER BY (user_seeks + user_scans + user_lookups) ASC

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

Этот DMV поддерживает только статистику с момента последнего перезапуска SQL Server; вид полностью уничтожен, и все начинается с нуля.

Что еще более важно, строки в этом представлении для любого определенного индекса удаляются при перестроении этого индекса (но не при его реорганизации). Если вы выполняете регулярное обслуживание индексов, может быть полезно просмотреть журналы обслуживания и посмотреть, не был ли недавно перестроен какой-либо из индексов, которые вы рассматриваете как удаление.

Таким образом, принятие решений на основе низкого чтения с момента последнего перезапуска, когда последний перезапуск, возможно, был для обновлений вторника патча прошлой недели или вчерашнего пакета обновления, может быть нецелесообразным. Или когда вы выполняете обслуживание индекса, начиная с последней перестройки. Может быть отчет, который запускается только один раз в месяц, один раз в квартал или один раз в год, и его готовит важный и нетерпеливый человек.

Кроме того, может существовать индекс для того, что произойдет в будущем, о котором вы не знаете - например, готовится серия отчетов для налогового сезона.

Итак, мой совет:

Используйте DMV, чтобы идентифицировать кандидаты в индексы для удаления , но не принимайте это решение в пузыре - вам нужно приложить немало усилий, чтобы определить, почему индекс может существовать, прежде чем удалять его, даже если он выглядит так, как будто он не используется в настоящее время ,

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

Еще одна вещь, которую следует учитывать, это то, что другие индексы находятся на столе. Возможно, он не привыкнет, потому что он в основном или полностью дублирует другой индекс. Да. Сервер SQL позволяет создавать два разных, но идентичных индекса, поэтому он может быть полностью избыточным.

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

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