Что вы делаете, чтобы новый индекс не замедлял запросы?

Question

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

1. запустить профилировщик,
2. запустить скрипт SQL, который содержит много запросов, которые я не хочу замедлять
3. загрузить трассировку из файла в таблицу,
4. анализирует ЦП, считывает и записывает данные трассировки по результатам предыдущих запусков, прежде чем я добавил (или удалил) индекс.

Это отчасти автоматизировано и делает то, что я хочу. Однако я не уверен, есть ли лучший способ сделать это. Есть ли какой-нибудь инструмент, который делает то, что я хочу?

Редактировать 1 Человек, который проголосовал за закрытие моего вопроса, не могли бы вы объяснить свои причины?

Редактировать 2 Я погуглил, но не нашел ничего, что объясняло бы, как добавление индекса может замедлить выбор. Однако это общеизвестный факт, поэтому где-то должно быть что-то. Если ничего не получится, я могу написать несколько примеров позже.

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

Другой пример - добавление индекса по возрастающему столбцу, например OrderDate, может серьезно замедлить запрос с условием вроде OrderDate> SomeDateAfterCreatingTheIndex.

Answer 1

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

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

Вы можете применить фиксированный план запроса к руководству плана типа ОБЪЕКТ или SQL. Руководства по планированию, применяющие фиксированный план запросов, полезны, когда вы знать о существующем плане выполнения, который работает лучше, чем один, выбранный оптимизатором для конкретного запроса.

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

Answer 2

Как насчет следующего подхода:

• Сохранить планы выполнения всех типичных запросов.
• После применения новых индексов проверьте, какие планы выполнения изменились.
• Проверка производительности запросов с измененными планами.

Answer 3

Хорошо. Во-первых, индекс замедляет две вещи (по крайней мере)

-> вставить / обновить / удалить: перестроить индекс

-> планирование запроса: «использовать этот индекс или нет?»

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

Если ваш оптимизатор хотя бы наполовину приличный, а ваша статистика / параметры верны, то он не сможет выбрать неправильный план.

В любом случае, в вашем случае (mssql) вы вряд ли можете доверять оптимизатору, и вам все равно придется проверять каждый раз.

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

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

Полное преобразование схемы БД - как проверить переписанные запросы?

Answer 4

со страницы «Настройка производительности запроса»

Улучшение индексов

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

Как и в большинстве методов оптимизации производительности, существуют компромиссы. Например, при большем количестве индексов запросы SELECT могут выполняться быстрее. Однако операции DML (INSERT, UPDATE и DELETE) значительно замедлятся, поскольку при каждой операции необходимо поддерживать больше индексов. Поэтому, если ваши запросы в основном представляют собой операторы SELECT, могут быть полезны дополнительные индексы. Если ваше приложение выполняет много операций DML, вы должны быть осторожны с количеством создаваемых вами индексов.

Другие ресурсы:

• http://databases.about.com/od/sqlserver/a/indextuning.htm

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

• http://searchsqlserver.techtarget.com/tip/Stored-procedure-to-find-fragmented-indexes-in-SQL-Server

Фрагментированные индексы и таблицы в SQL Server могут снизить производительность приложений. Вот хранимая процедура, которая находит фрагментированные индексы на серверах и базах данных SQL.