Какие факторы могут вызвать перекомпиляцию хранимых процедур на SQL Server?

Question

Какие факторы я должен знать, что может вызвать чрезмерную перекомпиляцию хранимых процедур?

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

Динамический SQL и переменные пути, приводящие к различным выводам (либо по типу данных и / или количеству столбцов), похоже, могут представлять проблему. Верны ли предположения? Есть ли другие примеры.

Редактировать: я нашел другой пример. Создание временной таблицы в операторе управления потоком приведет к перекомпиляции.

Answer 1

Существует несколько способов обеспечить перекомпиляцию хранимой процедуры:

• с использованием WITH RECOMPILE,
• делает хранимую процедуру динамической (представьте exec())
• маркировка proc для перекомпиляции с sp_recompile.
• изменение схемы, на которую опирается кэшированный план запросов
• звонит DBCC FREEPROCCACHE
• На уровне запроса отдельный оператор в процедуре может быть перекомпилирован с подсказкой запроса RECOMPILE (SQL 2008).

Факторы при перекомпиляции

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

• Вставка или удаление большого количества данных (плотность данных в индексах и таблицах часто контролирует планы запросов)
• Восстановление индексов (изменение базовых объектов)
• Создание / удаление временных таблиц (опять же, базовые изменения DML).
• План запросов устарел (подумайте, что он не использовался в последнее время, а sql хочет очистить использование памяти)

Это далеко не полный список. Оптимизатор запросов развивается и удивляется независимо от того, как долго вы используете SQL Server. Но вот некоторые ресурсы, которые могут быть полезны:

• Устранение неполадок при перекомпиляции хранимых процедур (старое, но вкусное)
• Повторное выполнение хранимых процедур
• Оптимизация хранимых процедур SQL Server для избежания перекомпиляции
• Кэширование и повторное использование плана выполнения (необходимо прочитать)

НО ЖДИТЕ - БОЛЬШЕ!

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

Так когда бы вы захотели перекомпилировать? Давайте посмотрим на один пример процесса, который ищет по фамилии. Хранимые процедуры выполняют ' параметр сниффинг ', что является благословением (если оно работает для вас) и проклятием (если оно работает против вас). Первый проход кто-то ищет на Zebr% для Зербровского. Индекс фамилии понимает, что это очень специфично и вернет, скажем, 3 строки из миллиона - так строится один план выполнения. С процедурой, скомпилированной для низкого результата строки, следующий поиск для S%. Ну, S - ваше самое распространенное имя и соответствует 93 543 строкам из 1 миллиона.

Answer 2

Некоторые параметры SET могут вызывать перекомпиляцию хранимых процедур или даже несколько перекомпиляций за одно выполнение!

Некоторые из этих параметров могут отсутствовать даже внутри SP

--this will cause recompilation
SET concat_null_yields_null ON;
EXEC spMyProc;

Некоторые из опций, которыевызывать перекомпиляцию, если внутри SP:

ARITHABORT

ANSI_NULLS

QUOTED_IDENTIFIER

К счастью, этот не вызывает перекомпиляции: SET NOCOUNT ON;