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

Question

У меня есть хранимая процедура с некоторыми параметрами (я использовал общий тип и имя, как раз для примера). Когда я его как код сильфона, он работает в течение двух минут:

create procedure [dbo].[name] 
     @param1 type, 
     @param2 type, 
     @param3 type, 
     @param4 type, 
     @param5 type, 
     @param6 type 
    as 
    begin 
     SELECT 
      COLUMNS 
     from 
      table1 t1 
      inner join table2 t2 on t1.id = t2.j_id 
      left join table3 t3 pn t2.column3 = t3.id 
      ............ 
     where 
      (@param1 is null or @param1 = some_column) 
      and (@param1 is null or @param1 = some_column) 
      and (@param1 is null or @param1 = some_column) 
      and (@param1 is null or @param1 = some_column) 
      and (@param1 is null or @param1 = some_column) 
      and (@param1 is null or @param1 = some_column) 
    end 

Но если изменить код и объявить переменные и использовать их в запросе, он работает в секунду. Зачем?

Вот «оптимизированный» код:

create procedure [dbo].[name] 
    @param1 type, 
    @param2 type, 
    @param3 type, 
    @param4 type, 
    @param5 type, 
    @param6 type 
as 
begin 
    declare 
     @var1 type = @param1, 
     @var2 type = @param2, 
     @var3 type = @param3, 
     @var4 type = @param4, 
     @var5 type = @param5, 
     @var6 type = @param6 
    SELECT 
     COLUMNS 
    from 
     table1 t1 
     inner join table2 t2 on t1.id = t2.j_id 
     left join table3 t3 on t2.column3 = t3.id 
     ............ 
    where 
     (@var1 is null or @var1 = some_column) 
     and (@var2 is null or @var2 = some_column) 
     and (@var3 is null or @var3 = some_column) 
     and (@var4 is null or @var4 = some_column) 
     and (@var5 is null or @var5 = some_column) 
     and (@var6 is null or @var6 = some_column) 
end 

Почему второй вариант хранимой процедуры работает гораздо быстрее?

Answer 1

на основе @ lad2025, вот почему он работает быстрее:

Обход: Использование локальной переменной

• Этот способ очень похож с предыдущим (OPTION (Оптимизировать (@VARIABLE UNKNOWN)))
• при задании на локальный Счетчик того SQL Server использует статистические плотности вместо статистических гистограмм
• Так он оценивает такое же количество записей для всех PARAMATERS
• Недостаток заключается в том, что некоторые запросы будут использовать субоптимальные планы, поскольку плотности не являются достаточно точными, как статистическая гистограмма. нюхают

http://blogs.msdn.com/b/turgays/archive/2013/09/10/parameter-sniffing-problem-and-workarounds.aspx