Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Всем привет.
Ситуация.
Есть некая inline table-valued function, которая входит в запрос в хранимую процедуру.
Функция использует xml преобразование, и ее использование, судя по execution plan, ощутимо влияет на общий performance.
Но при этом ее использование имеет смысл только при определеных значенях параметра хранимой процедуры.
Но, даже если я в явном виде прописываю вызов этой функции с дополнительным условием, она, судя по execution plan, все равно выполняется, независимо от этого условия.
В упрощенном виде этот факт выглядит так - см скрин в атачменте.
То есть WHERE условие накладываетя уже как бы после выполнения функции.
Причем если поставить условие WHERE 1=0 - тогда заход в функцию не происходит.
Есть способы обойти такое поведение, кроме Dynamic SQL?
Спасибо.
Условие 0=1 заведомо даёт один и тот же результат всегда,
а значение переменной @Find_What заранее неизвестно и
она равна некоторому значению по умолчанию в момент компиляции (если ничего не делать, то NULL).
Видимо, именно для этого значения оптимизатор и подбирает оптимальный план.
invmMcCarЭто все понятно, но в run-time он в эту функцию реально заходит, и только после этого оценивает условие.Вы этот вывод сделали из формы плана?
Похоже вывод был неправильный.
Реальное значение "Number of Executions" там ноль.
Заказчик тут панику поднял что 100% стоимости запроса занимает вызов этой функции.
Спасибо
1 - option(recompile)
select Str_Out from ...
where @find_what is not null
option(recompile)
2. значений тут 2 можно и простым условием сделать...
if @find_what is not null
select Str_Out from ...
where @find_what is not null
else
select Str_Out from ...
--where @find_what is not null
-- KAB --у вас parameter sniffing...Нет там такого. Посмотрите внимательнее на предикат в where.
С этим запросом вообще озвученной проблемы нет, потому что в одном из фильтров на внешнем входе первого NL срабатывает Startup Expression Predicate по @Find_What is not null.
Что ТС и подтвердил - 21884204 .
