Следует ли вам всегда предвидеть проблемы, вызванные анализом параметров?

Question

Используя SQL Server 2008, у меня есть простая хранимая процедура, содержимое которой

DELETE FROM [ABC].[dbo].[LookUpPermissions] 
WHERE Code = @Code

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

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

---

edit
Это применимо только к параметрам, используемым впредложение WHERE , или, например, нужно ли вам учитывать все параметры в операторе INSERT ?

Answer 1

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

В качестве примера, представьте запрос, который ищет строки, в которыхстолбец даты находится между @start_date и @end_date.Вызов процедуры с диапазоном дат 2 дня может создать / кэшировать план выполнения, который не оптимален для диапазона дат 1 год.

Answer 2

Параметр Sniffing - это еще одна встроенная «умная штуковина» (не забывайте о проверке встроенных заклинаний / грамматик), которую Microsoft использует для оптимизации запросов SQL.Анализируя входные параметры, SQL Server делает наиболее обоснованное предположение о том, какой план кэшированных запросов будет наилучшим для использования.Это не всегда делает правильный выбор.

Прочтите это для получения информации о том, как обмануть SQL, чтобы не использовать анализатор Pramater .