Я запускаю инструмент автоматического индексирования в нашей базе данных MS SQL (я изменил скрипт, созданный Microsoft, который просматривает таблицы статистики индекса - Automated Auto Indexing ). Из статистики у меня теперь есть список рекомендаций для индексов, которые нужно создать.

Редактировать: описанные выше индексы берут информацию из DMV, которая сообщает вам, что ядро ​​базы данных использовало бы для индексов, если бы они были доступны, а сценарии берут рекомендации Top x (по поиску, влиянию пользователя и т. Д.) И помещают их в таблицу.

(Правка выше частично взята из ответа Ларри Коулмана ниже, чтобы уточнить, что делают сценарии)

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

Нужно ли запускать SQL Profiler или лучше изучить код, который запрашивает таблицы? И есть ли у вас другие советы?

Я использую сценарии анализа индекса Джейсона Стейта (Старая локация) . Они сообщают вам, сколько ваших существующих индексов используется, а также сколько недостающих индексов было бы использовано. Обычно я не добавляю индексы, если они не составляют более 5 или 10% запросов к таблице.

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

Обновление: статьи блога по анализу индекса Jason Strate для новых сценариев (Новое местоположение)

Двойное обновление: в эти дни я использую sp_BlitzIndex® при выполнении анализа индекса.

Есть несколько понятий и терминов, которые важно понимать при работе с индексами. Поиск, сканирование и поиск - вот некоторые из способов использования индексов через операторы select. Избирательность ключевых столбцов является неотъемлемой частью определения эффективности индекса.

Поиск происходит, когда оптимизатор запросов SQL Server определяет, что лучший способ найти запрошенные вами данные - это сканирование диапазона в индексе. Поиск обычно происходит, когда запрос «покрывается» индексом, что означает, что предикаты поиска находятся в ключе индекса, а отображаемые столбцы либо в ключе, либо включены. Сканирование происходит, когда оптимизатор запросов SQL Server определяет, что наилучшим способом поиска данных является сканирование всего индекса, а затем фильтрация результатов. Поиск обычно происходит, когда индекс не включает все запрошенные столбцы, либо в ключе индекса, либо во включенных столбцах. Затем оптимизатор запросов будет использовать кластеризованный ключ (для кластеризованного индекса) или RID (для кучи) для «поиска» других запрошенных столбцов.

Как правило, операции поиска более эффективны, чем сканирование, из-за физического запроса меньшего набора данных. Существуют ситуации, когда это не так, например, очень маленький набор начальных данных, но это выходит за рамки вашего вопроса.

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

Чтобы определить, насколько эффективен индекс, вы должны определить селективность ключей индекса. Избирательность может быть определена как процентное соотношение отдельных записей к общему количеству записей. Если у меня есть таблица [person] со 100 записями, а столбец [first_name] содержит 90 различных значений, мы можем сказать, что столбец [first_name] селективен на 90%. Чем выше селективность, тем эффективнее индексный ключ. Помня о селективности, лучше всего указывать наиболее селективные столбцы в ключе индекса. Используя мой предыдущий пример [person], что если бы у нас был столбец [last_name], который был на 95% избирательным? Мы бы хотели создать индекс с [last_name], [first_name] в качестве ключа индекса.

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

Недавно я обнаружил фантастический бесплатный сценарий от людей из BrentOzar Unltd http://www.brentozar.com/blitzindex/

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

Это руководство, как правило, хорошо. Иногда это становится немного наводящим на размышления об идеях. Пока я обычно делал следующее:

• Удалены индексы, которые НИКОГДА не читались (или, возможно, менее 50 раз в месяц).
• Добавлены наиболее очевидные индексы для внешних ключей и полей, которые, как я знаю, мы часто используем.

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

Как правило, вы должны избегать индексов на:

• Очень маленькие таблицы (менее 50-200 записей): часто механизм запросов работает быстрее, если он сканирует таблицу, а не загружает индекс, читает, обрабатывает его и т. Д.
• Избегайте индексов для столбцов с низким уровнем мощности ( http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) ) в первом упомянутом столбце. Например, индексирование гендерного поля (M / F) очень мало полезно, так же практично сканировать таблицу и находить ~ 50%, которые соответствуют. Если он указан после чего-то более конкретного в индексе (например, [дата рождения, пол]), это лучше - вы можете пожелать, чтобы все мужчины родились за определенный промежуток времени.

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

Я сократил некоторые таблицы с 900 МБ до 400 МБ только потому, что они были заранее неиспользованными кучами. http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx

Реорганизовать / Rebuild

Вы должны искать фрагментированные индексы. Немного фрагментации - все в порядке, не становитесь навязчивыми! http://technet.microsoft.com/en-us/library/ms189858.aspx Знайте разницу между реорганизацией и перестройкой!

Регулярно просматривайте

Изменяются запросы, меняются объемы данных, добавляются новые функции, удаляются старые. Вы должны смотреть на них один раз в месяц (или чаще, если у вас большие объемы) и искать, где вы можете помочь базе данных!

Сколько

В недавнем видео Брент рекомендует (как правило) не более 5 индексов для таблицы с большим количеством записей (например, таблицы заказов) и не более 10, если оно читается намного больше, чем записано (т. Е. Таблица регистрации для аналитики) http: / /www.youtube.com/watch?v=gOsflkQkHjg

В целом

По-разному!

Ваш пробег варьируется в зависимости от базы данных. Покройте очевидные (фамилия сотрудника, дата заказа и т. Д.) На ваших (текущих / будущих) больших таблицах. Контролируйте, просматривайте и корректируйте по мере необходимости. Это должно быть частью вашего обычного контрольного списка при управлении вашей базой данных :)

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

Обычно это происходит при наличии определенной рабочей нагрузки (запросов) и тщательном тестировании влияния каждого нового индекса на рабочую нагрузку. Этот итеративный процесс должен всегда включать тщательный анализ планов выполнения, который бы показал, какие индексы используются. Тема анализа запроса довольно длительная, и начать с отдельной главы MSDN « Анализ запроса» - хорошая ставка.

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

Так что, если вы следуете моей идее, добавление индекса и измерение воздействия - это на самом деле всего лишь случай A / B-тестирования : вы выполняете свою нагрузку без индекса как базовую строку, а затем запускаете ее с индексом, измеряете и сравниваете с базовой линией, а затем решить, основываясь на наблюдаемых и измеренных метриках, если воздействие является полезным. Рабочая нагрузка лучше всего подходит для тестирования хорошего качества, но она также может быть воспроизведением захваченной рабочей нагрузки, см. Как: воспроизвести файл трассировки .

Более синтетический ответ - взглянуть на sys.dm_db_index_usage_statsпредставление и посмотреть, как используются индексы, но обычно это подход для проведения анализа на месте с неизвестной рабочей нагрузкой (т. Е. Консультант, вызванный для помощи, вероятно, начал бы с этого).

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

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

^{Смотрите также: официальные документы MS DMV}

Это зависит от того, как эта таблица используется. Например, допустим, у меня есть таблица, которая читается много раз, но обновления и вставки встречаются редко. Кроме того, я всегда запрашиваю таблицу в каком-то столбце внешнего ключа. Будет иметь смысл создавать (не кластеризованный) индекс по этому внешнему ключу для ускорения запросов на чтение. Но недостатком является то, что ваша вставка, обновление станет медленным.

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