Удаление неиспользуемых индексов - Оценка неожиданных опасностей

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

1. Прежде чем мы отбрасываем индекс, нам нужно убедиться, что он не обеспечивает ограничение уникальности, так как оптимизатору запросов может понадобиться этот индекс для существования.
2. Всякий раз, когда создается индекс, статистика, связанная с этим индексом, также создается в SQL Server. Запрос может не использовать индекс, но он может использовать свою статистику. Таким образом, мы можем столкнуться с ситуацией, после отбрасывания индекса производительность конкретного запроса ухудшается. SQL Server не хранит статистику использования статистики. Хотя в нашей базе данных включена функция «Автоматическое создание статистики», я не знаю, какие все параметры должны быть выполнены внутри, прежде чем оптимизатор запросов создаст недостающую статистику.

Что касается # 1, мне кажется, что SQL Server действительно будет выполнять поиск по индексу, чтобы определить уникальность, прежде чем будет выполнена вставка / обновление, и, следовательно, индекс не будет отображаться как неиспользуемый.

Что касается № 2, это действительно возможно?

Кстати, когда я говорю, что индекс не используется, я имею в виду отсутствие поиска и сканирования.

Обеспокоенность вашего DBA действительна.

Что касается # 1, мне кажется, что SQL Server действительно будет выполнять поиск по индексу, чтобы определить уникальность, прежде чем будет выполнена вставка / обновление, и, следовательно, индекс не будет отображаться как неиспользуемый.

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

Что касается № 2, это действительно возможно?

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

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

Ваш администратор баз знает свои вещи.

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