Помимо бесполезной траты места в базе данных, ненужные индексы на SQL Server могут замедлить операции вставки и обновления. Разработчики, не имеющие опыта в принципах работы с базами данных, иногда склонны создавать индексы таблиц, которые не имеют смысла для выполняемых запросов.
Существует ли общая процедура или инструмент для SQL Server 2005/2008 для анализа рабочей нагрузки базы данных и подсказок, какие индексы никогда не используются или не нужны для определенной операционной базы данных?
Спасибо!
При использовании sys.dm_db_index_usage_stats следует помнить несколько вещей:
Надеюсь это поможет.
PS Еще одна вещь для тех, кто читает это и задается вопросом, есть ли эквивалентный метод для SQL Server 2000 - нет, мы (поскольку я был в команде в то время) добавили возможность только для 2005 года и далее.
Я вижу здесь симпатичный маленький скрипт 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 Я собираюсь взглянуть на некоторые производственные базы данных, которые я создал, чтобы увидеть, как выглядит эта статистика. (улыбка)
Изменить: здесь есть очень хороший дополнительный фон: http://blogs.msdn.com/craigfr/archive/2008/10/30/what-is-the-difference-between-sys-dm-db-index-usage-stats-and-sys-dm-db- index-operating-stats.aspx
У нас есть вики-статья на SQLServerPedia со сценарием для этого, а также обучающее видео о том, как его использовать:
Один для поиска неиспользуемых индексов:
http://sqlserverpedia.com/wiki/Find_Indexes_Not_In_Use
И еще один, чтобы найти индексы, вы должны добавить:
попробуйте левое присоединение к 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 запрашивал добавление всех оставшихся столбцов таблицы в качестве столбцов «Включить» в индекс для таблицы с очень динамичный контент был сдерживающим фактором, который мне нужен, чтобы не автоматизировать процесс.
Я все еще использую свои сценарии, но применяю бизнес-решения моей компании к тому, что я делаю - то, что я могу делать в небольшой компании.
Как всегда, знайте свои данные, знайте свой бизнес, знайте направление своего бизнеса.