«IF..ElseIf..Else» или «Где пункт» для поводырей хранимых процедур приводит к

Question

У меня есть следующие два SQL заявления

Первый один:

IF(@User_Id IS NULL) 
BEGIN 
     SELECT * 
     FROM [UserTable] 
END 
ELSE   
BEGIN     
     SELECT * 
    FROM [UserTable] AS u 
    WHERE u.[Id] = @User_Id     
END 

Второй один:

SELECT * 
FROM [UserTable] AS u 
WHERE (@User_Id IS NULL OR u.[Id] = @User_Id) 

Оба этих запроса будут завернуты в собственную хранимую процедуру. Я подозреваю, что оператор IF вызывает много перекомпиляции SQL. Я столкнулся либо с разделением каждой части оператора IF на свою собственную хранимую процедуру, либо с заменой всей инструкции IF предложением WHERE (показано выше во втором заявлении SQL)

Мой вопрос: в чем разница между два утверждения с точки зрения производительности и как SQL обрабатывает каждое утверждение?

Спасибо.

Answer 1

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

Первое решение оптимизатора запросов может придумать лучший план для каждого из двух разных запросов. Первый запрос (в ветви NULL IF) не так много, что можно оптимизировать, но второй (в ветке NOT NULL идентификатора) можно оптимизировать, если существует индекс в столбце Id.

Но второе решение - это катастрофа для оптимизации. Независимо от значения параметра @User_Id, оптимизатор должен разработать план, который работает для любого значения. Таким образом, независимо от значения @User_Id, план будет всегда использовать субоптимальное сканирование таблицы. Существует просто нет пути вокруг этой проблемы, и это не параметр нюхать, как некоторые могут подумать. Это просто правильность плана, даже если значение при создании плана не равно NULL, план должен работать, даже если параметр равен NULL, поэтому он не может использовать индекс на Id.

Всегда, всегда, всегда используйте первую форму с явным IF.