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


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

Существует ли общая процедура или инструмент для SQL Server 2005/2008 для анализа рабочей нагрузки базы данных и даются подсказки, какие индексы никогда не используются или не нужны в определенной операционной базе данных?

Спасибо!


5
2018-06-04 13:45


Источник




Ответы:


Я вижу симпатичный маленький T-SQL-скрипт здесь (http://blog.sqlauthority.com/2008/02/11/sql-server-2005-find-unused-indexes-of-current-database/), чтобы показать неиспользуемые индексы, которые должны выполняться на SQL Server 2005. Другой http://aspadvice.com/blogs/ssmith/archive/2008/03/31/Find-Unused-SQL-2005-Indexes-for-Current-DB.aspx здесь тоже.

Похоже, что dm_db_index_usage_stats - ключ ко всему этому. Довольно аккуратно! (Видеть http://msdn.microsoft.com/en-us/library/ms188755.aspx  Мне нужно взглянуть на некоторые базы данных производства, которые я создал сейчас, чтобы посмотреть, как выглядят эти статистические данные. (улыбка)

Изменить: Некоторые очень приятные addt'l фона здесь: http://blogs.msdn.com/craigfr/archive/2008/10/30/what-is-the-difference-between-sys-dm-db-index-usage-stats-and-sys-dm-db- индекс-оперативно-stats.aspx


5
2018-06-04 13:59



Вы находитесь на правильном пути здесь, но имейте в виду это решение (DMV работает только в SQL 2005 или выше) - SQLChicken
Хорошо, что плакат спросил о SQL Server 2005/2008, а? улыбка - Evan Anderson
Lol хороший звонок, пропустил тот. - SQLChicken


Несколько вещей, которые нужно помнить об использовании sys.dm_db_index_usage_stats:

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

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

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


5
2018-06-04 15:09





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

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

http://sqlserverpedia.com/wiki/Find_Indexes_Not_In_Use

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

http://sqlserverpedia.com/wiki/Find_Missing_Indexes


4
2018-06-04 14:20



Проголосовали за то, чтобы противостоять отрицательному голосу без причины. Кроме того, видеоуроки всегда полезны. - SQLChicken
Спасибо, Брент! Я читаю это на своем мобильном телефоне, поэтому я не могу проверить видео в этот момент. Описывает ли этот учебник только то, как найти отсутствующие индексы или также ненужные? - splattne
Doh! Извините, я отправил неверную ссылку. Я добавил еще одну ссылку для той, которую вы хотели. Есть учебник по отсутствующим индексам и учебник по ненужным индексам, и я вставил не тот, хахаха. - Brent Ozar


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

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

Дэйв Дж

Редактировать: Эван победил меня, но он на месте.

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


2
2018-06-04 14:07





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


1
2018-06-04 15:17





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

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

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

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

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


0
2018-06-04 16:37