SQL Server 2008 хранится в лучших практиках оптимизации или нескольких условий

Question

Вопрос касается производительности и лучших практик.(хранимая процедура sql server 2008)

Если хранимый процесс содержит код, подобный этому

result = select count(*) from tableA where (some condition1)

if (result) -- meaning we got something from above query
   return result
else
   result = select count(*) from tableA where (some other condition2)
and so on until
result = select count(*) from tableA where (some other conditionN)

Лучше ли поместить все условия в один большой запрос, подобный этому

   resultn = select count(*) from tableA 
   where (condition1 or condition1 or... conditionN)

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

Answer 1

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

Предполагается, что при каждом выборе будет полное сканирование ...

и ваши предложения WHERE отличаются, вам придется включить эту логику в выборку, используя CASE WHEN

см .: http://msdn.microsoft.com/en-us/library/aa258235(v=sql.80).aspx

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

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

Answer 2

Ваши два кодовых блока не являются логически эквивалентными.Я собираюсь предположить, что IF(result) действительно означает, IF(@result > 0).В этом случае будет возвращен первый ненулевой счет, который вы найдете.Во втором блоке кода вы фактически получите общее количество всех значений по всем вашим критериям.

Во втором блоке кода SQL Server может выбрать только один план запроса для запроса.Если у вас есть индексы для всех ваших столбцов, он все равно может использовать только один из них.Я не думаю , что он будет выполнять параллельную обработку с использованием индекса для каждого условия запроса.Хотя я специально не проверял это, так что, возможно, кто-то может исправить меня, если я ошибаюсь.Возможно, вам удастся решить эту проблему с помощью директивы WITH RECOMPILE в вашей хранимой процедуре.В SQL 2005 были некоторые ошибки, но поскольку вы работаете с SQL 2008, все должно быть в порядке.

В вашем первом блоке кода SQL Server может иметь отдельные планы запросов для каждого запроса.

Влюбой случай, который на самом деле лучший будет зависеть от множества факторов.Лучше всего будет тестировать их бок о бок с тестовыми данными, которые очень близко имитируют ваши фактические производственные данные.

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

Наконец, условия зависят от параметров хранимой процедуры?Будут ли некоторые из этих параметров часто опущены, что означает, что условие не имеет значения?Если это так, то вам следует очень внимательно прочитать эту статью об условиях динамического поиска Эрланда Соммарскога.На одном клиенте я обнаружил, что динамический SQL является наиболее эффективным методом на данный момент для этой ситуации, но, конечно, нужно было приложить много усилий, чтобы сделать этот код герметичным, когда речь заходит о безопасности.

Answer 3

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