Эта практика приводит к путанице в оптимизаторе запросов. Я видел, как SQL Server 2000 строил план выполнения с точностью до наоборот и использовал индекс для Column1, когда был установлен флаг, и наоборот. Казалось, что SQL Server 2005, по крайней мере, правильно разработал план выполнения при первой компиляции, но у вас возникла новая проблема. Система кэширует скомпилированные планы выполнения и пытается использовать их повторно. Если вы сначала используете запрос одним способом, он все равно выполнит запрос таким образом, даже если изменится дополнительный параметр, и более подходящими будут другие индексы.
Вы можете принудительно перекомпилировать хранимую процедуру при выполнении, используя WITH RECOMPILE
в операторе EXEC
или каждый раз, указав WITH RECOMPILE
в операторе CREATE PROCEDURE
. За повторный анализ и оптимизацию запроса SQL Server будет налагаться штраф.
Как правило, если форма вашего запроса изменится, используйте динамическую генерацию SQL с параметрами . SQL Server также будет кэшировать планы выполнения для параметризованных и автоматически параметризованных запросов (где он пытается определить, какие аргументы являются параметрами) и даже для обычных запросов, но он придает больше значения планам выполнения хранимых процедур, затем параметризованным, автоматически параметризованным регулярные запросы в этом порядке. Чем больше вес, тем дольше он может оставаться в оперативной памяти до того, как план будет удален, если серверу понадобится память для чего-то другого.