Можно ли слепо добавлять недостающие индексы?

Я часто использую SSMS для проверки моих медленных хранимых процедур на предмет отсутствия индексов. Всякий раз, когда я вижу «Отсутствующий индекс (Impact xxx)», моя реакция на коленях - просто создать новый индекс. Насколько я могу судить, это приводит к более быстрому запросу каждый раз.

Любая причина, почему я не должен продолжать делать это?

Много причин.

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

Пример:

У вас есть стол с ColA, ColB, ColC.

В настоящее время у вас есть индекс на ColA. Отсутствующий индекс DMV предложит вам добавить индекс (ColA, ColB). Это может быть правильно, но разумно добавить ColBвторой ключ к существующему индексу. В противном случае вы получите дублирующее покрытие и потраченное впустую пространство и накладные расходы.

Точно так же, если у вас есть индекс ColB INCLUDE (ColA), он может предложить индекс на ColB INCLUDE (ColC). Опять же, разумно добавить ColCв список включения в существующем индексе.

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

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

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

Я рекомендую осторожно использовать эту технику настройки, поскольку я обнаружил, что отсутствующие предложения по индексам, появляющиеся в планах запросов, неизменно оказываются менее надежными, поскольку запросы и схемы БД становятся все более сложными. По моему опыту, это объясняется множеством причин:

1) «Улучшение в процентах» может быть далеко не для всех, кроме простейших запросов / наиболее очевидных индексов, в конце концов, это всего лишь оценка и не зависит от фактических затрат или фактического количества строк при выполнении запроса Я видел, как после внедрения предложенного индекса стоимость запросов возрастает, или он даже не используется, и план остается прежним.

2) Сам план запроса не является оптимальным, либо из-за построения запроса (соединения и где предложение не оптимизировано и т. Д.), Либо из-за отсутствия / устаревшей статистики оценки количества строк отключены. Индексирование для крайне плохого плана запросов часто в лучшем случае является решением с бинтами, но только с постепенным улучшением производительности.

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

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

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

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