Способ поиска ненужных индексов операционной базы данных SQL Server?

Об использовании sys.dm_db_index_usage_stats следует помнить несколько вещей:

1. Вывод содержит только индексы, которые использовались с момента последнего запуска базы данных. Когда база данных закрыта, все записи из кэша в памяти информации для этой базы данных удаляются. Точно так же кеш не переживает мгновенный перезапуск. Невозможно вручную очистить записи для конкретной базы данных без перезапуска базы данных. В различных статьях, на которые есть ссылки в первом ответе (а также в моем блоге), описывается, как захватывать выходные данные в разное время для анализа временных рядов.
2. Обязательно протестируйте весь свой деловой цикл. Вы не хотите удалять индекс, который используется для отчета на конец месяца или запроса генерального директора, даже если это может показаться заманчивым.
3. Убедитесь, что вы понимаете различные значения и их значение, прежде чем принимать решение о том, используется ли индекс с выгодой или просто ведется за счет средств.

Надеюсь это поможет.

PS Еще одна вещь для других, читающих это и задающихся вопросом, существует ли эквивалентный метод для SQL Server 2000 - нет, мы (как я был в команде в то время) только добавили возможность для 2005 года.

У нас есть вики-статья на SQLServerPedia со сценарием для этого, а также обучающее видео о том, как его использовать:

Один, чтобы найти индексы, которые не используются:

http://sqlserverpedia.com/wiki/Find_Indexes_Not_In_Use

И еще, чтобы найти индексы, вы должны добавить:

http://sqlserverpedia.com/wiki/Find_Missing_Indexes

Попробуйте присоединиться к select * из Sys.dm_db_index_usage_stats. Вы можете увидеть, которые никогда не были затронуты. Удостоверьтесь, что они были достаточно длинны, хотя, выполнение этого на следующий день после создания нового индекса может оказаться недостаточным.

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

Дэйв Дж

Изменить: Эван победил меня, но он на месте.

Редактировать 2: исправленный совет, забыл бит анти-объединения!

Я сделал запрос, связанный с индексами, и показал это в своем блоге ( http://dbalink.wordpress.com/2008/11/09/how-to-finding-index-usage-stats-with-dmv-in-tsql/)

Имейте в виду, что SQL Server не знает вашего бизнеса. Она не знает, какие бизнес-тактические и стратегические решения приняла и будет принимать ваша компания.

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

Когда мы работали с SQL Server RTM, я написал свои собственные сценарии для просмотра и составления отчетов о таблицах DM и подумал об автоматизации их деятельности. Один взгляд на отсутствующий индексный отчет, где SQL Server запрашивал добавление всех оставшихся столбцов таблицы в качестве столбцов "Включить" в индекс для таблицы с очень динамичным содержимым, был сдерживающим фактором, который мне был необходим, чтобы не автоматизировать процесс.

Я все еще использую свои сценарии, но я применяю бизнес-решения моей компании к тому, что я делаю - что-то, что я могу сделать в небольшой компании.

Как всегда, знайте свои данные, знайте свой бизнес, знайте направление своего бизнеса.