Хранимые процедуры и оптимизировать для неизвестных - PullRequest
Новая
       12

Хранимые процедуры и оптимизировать для неизвестных

3 голосов
/ 04 декабря 2010

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

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

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

Мне кажется, это говорит о том, что любой параметр, передаваемый в хранимый процесс, будет "сниффирован", что поможет SQLСервер для составления оптимального плана выполнения.Это подразумевает, что кэшированный план будет пересмотрен / перекомпилирован (не уверен в этом механизме).Однако это сбивает с толку, поскольку сводит на нет всю необходимость ОПТИМИЗИРОВАТЬ ДЛЯ НЕИЗВЕСТНЫХ.

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

Может ли кто-нибудь ответить на этот вопрос для меня, в идеалес указателем на что-то от Microsoft, которая проясняет это.Спасибо.

1 Ответ

7 голосов
/ 04 декабря 2010

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

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

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

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

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

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

...