Сохраненные процедуры и ОПТИМИЗАЦИЯ ДЛЯ НЕИЗВЕСТНОГО

Question

Я читал об подсказке запроса SQL Server 2008 OPTIMIZE FOR UNKNOWN. Я понимаю, как это работает.

Тем не менее, у меня есть вопрос по поводу , где и , когда использовать его. Он не может быть указан внутри UDF. Он может быть указан внутри хранимой процедуры. Тем не менее, this MSDN блог разместить гласит следующее:

4.Moving запрос в хранимую процедуру можно поместить его в отдельную процедурного контекста и может быть хорошим способ получить это значение, видимую оптимизатора (Примечание: это работает в SQL 2000, а)

это, мне кажется, можно сказать, что любой параметр, передаваемый хранимая процедура будет «нюхал», тем самым помогая SQL Server для составления оптимального плана выполнения. Это подразумевает, что кэшированный план будет пересматриваться/перекомпилироваться (не уверен в этом механизме). Однако это путает, потому что это отрицает всю потребность в OPTIMIZE for UNKNOWN.

Статья MSDN по подсказкам запроса не распространяется на мой вопрос.

Может кто-то ответить на этот вопрос для меня, в идеале указатель на что-то от Microsoft, который очищает это. Благодарю.

Answer 1

Поведение SQL-компилятора по умолчанию заключается в использовании значений любых параметров, заданных при первом выполнении SP, чтобы оптимизировать план (см. Параграфы 2 и 3 из this MSDN article on SP recompilation). Этот план затем кэшируется для повторного использования до тех пор, пока он не покинет кеш - много деталей в процессе кэширования плана here.

В блоге MSDN, который вы цитируете, отмечается, как облегчить этот процесс для компилятора; Я думаю, что пункт 4 (цитируемый в вопросе) предполагает, что это преимущество хранимых процедур над специальным SQL.

Подсказка OPTIMIZE FOR UNKNOWN указывает компилятору на aviod по умолчанию; что он должен игнорировать значения параметров, указанные в первом выполнении, и выбирать более обобщенный план. Это более экстремальная версия пункта 2 в списке предложений в конце сообщения в блоге, указанном в вопросе;

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

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

Рассмотрите возможность использования OPTIMIZE FOR UNKNOWN в обстоятельствах, указанных в пункте 2, - когда один и тот же запрос дает очень переменную производительность, поскольку в некоторых случаях план плох при типичных параметрах - обычно, когда параметры в столбцах фильтра запроса имеют очень переменную мощность.