Я где-то читал, что второй способ приведет к короткому замыканию и никогда не оценит вторую часть, если она истинна. Мой администратор базы данных сказал, что он вызывает сканирование таблицы.
Вы читаете неправильно; он не приведет к короткому замыканию , а не . Ваш администратор базы данных прав; он не будет работать с оптимизатором запросов и, скорее всего, вызовет сканирование таблицы.
Первый вариант почти настолько хорош, насколько это возможно. Ваши варианты улучшения - это динамический sql или длинная хранимая процедура со всеми возможными комбинациями столбцов фильтра, чтобы вы получали независимые планы запросов. Вы также можете попробовать использовать опцию «WITH RECOMPILE», но я не думаю, что это вам поможет.
, если вы используете SQL Server 2005 или более поздней версии, вы можете использовать IF для создания нескольких версий запроса с правильным WHERE, чтобы можно было использовать индекс. Каждый план запроса будет помещен в кэш запросов.
также, вот очень исчерпывающая статья по этой теме:
Условия динамического поиска в T-SQL, Эрланд Соммарског
, в ней рассматриваются все вопросы и методы попытка написать запросы с несколькими необязательными условиями поиска
вот оглавление:
Introduction The Case Study: Searching Orders The Northgale Database Dynamic SQL Introduction Using sp_executesql Using the CLR Using EXEC() When Caching Is Not Really What You Want Static SQL Introduction x = @x OR @x IS NULL Using IF statements Umachandar's Bag of Tricks Using Temp Tables x = @x AND @x IS NOT NULL Handling Complex Conditions Hybrid Solutions – Using both Static and Dynamic SQL Using Views Using Inline Table Functions Conclusion Feedback and Acknowledgements Revision History
. Если вы передадите нулевое значение, когда вам нужно все, тогда вы можете написать предложение where как
Where colName = IsNull(@Paramater, ColName)
Это в основном то же самое, что и ваш первый метод ... он будет работать, пока сам столбец не допускает значения NULL ... Нулевые значения IN столбец немного испортит его.
Единственный подход к его ускорению заключается в добавлении индекса к фильтруемому столбцу в предложении Where. Уже есть? Если нет, это приведет к резкому улучшению.
Я не могу придумать другого способа сделать:
WHERE
(MyCase IS NULL OR MyCase = @MyCaseParameter) И ....
Второй вариант проще и понятнее для разработчиков, если вы спросите меня.