Здесь ничем :) Действительно функция будет вызвана только на полученные отфильтрованные записи.

Однако например, если в функцию вставить какой нибудь SQL запрос, то мы получим вызов этого запроса столько раз, сколько получилось строк после фильтрации основного запроса. В плане запроса естественно такой "подзапрос" обработаться и отобразиться не может, поэтому скорее всего такая уже функция будет тормозить выполнение запроса тем, что постоянно генерить еще запросы, на которые оптимизатору тоже надо строить план запроса и не факт, что он удачно осядет в кэше, плюс на время выполнения таких вот запросиков будут идти постоянные блокировки/разблокировки и т.д. Работы как говориться будет делаться много.

Далее еще важный пример : обычная скалярная функция, пусть даже туда параметром передается константа, но участвует такая функция в групповом фильтре:

Здесь сначала будут посчитаны суммы всех групп Id, а потом проведена фильтрация по Id = 100, что не очень приятно и приводит к Table Scan таблицы.

Следующий скрипт на пару строчек больше, но выполняется в разы быстрее:

По плану здесь сначала будете применен фильтр по Id = 100, в том числе по индексу, если Id проиндексированно. Далее уже по полученым записям будут проведены группировки и аггрегирование.

Думаю наглядно видно, что здесь функция не очень катит - в первом случае будут последовательно сканиться все записи таблицы, во втором ровно столько, сколько надо.

Вообще я бы сказал, что любое использование пользовательских функций для задания связей таблиц, фильтрующих условий, сортировки и т.д. чревато большими тормозами. Это не относиться к системным функциям, которых ASA в состоянии оптимизировать и красиво включить в план запроса.

Вот вроде и все мысли по поводу UDF :)

Первый if ничего страшного не делает - это обычное вычислямое поле в запросе. А вот со вторым if Вы конечно погорячились. Если посмотреть план запросов, то будет организовано 2 subquery и они оба будут выполняться, а полученный результат участвовать в фильтре в зависимости от Условия2. Вот такие вещи я и не рекомендую делать - фактически Вы режите работу оптимизатора на корню, на малых обьемах этого не будет заметно, а вот если в таблице миллионы записей, то долгое ожидание выполнения запроса гарантированно. Если у Вас Условие2 статично, то гораздо легче написать вот так:

План такого запроса будет примитивным и быстрым. Если же у Вас в Условие2 участвуют поля, то однозначно такой запрос вообще надо переписывать по другому или же задуматься об правильности организации структуры БД. Как один из вариантов более легкой для оптимизатора версии запроса:

Здесь план запроса будет приличным, никаких Subquery и при наличие нужных индексов оптимизатор сможет ими нормально воспользоваться. Я рекомендую себе взять за правило, что конструкция такого типа:

будет всегда медленней работать, чем:

фильтрация по наборам данных с помощью OR всегда медленнее, чем с помощью UNION ALL, и IN во многих случаях может оказаться медленнее, чем INNER JOIN, особенно на больших обьемах данных.

авторЕсть еще одна проблема: есть шапка счета (t_invoice), есть содержание (t_order).
Понятно, что постоянно нужна сумма счета.
Как быть? Сейчас везде считается подзапросом.
Очень хочется иметь сумму без вычислений.
Можно в триггере, но иногда необходимо править t_order без триггеров.
Плюс, у нас распределенная база (SQL Remote) и без триггеров могут работать админы в филиалах, а сумму хотелось бы иметь корректную.
Как быть?
Если записей в содержании на запись в шапке счета мало, то легче действительно просто считать, скорость при этом не потеряется. Если записей много, то все действительно лучше через триггера - делаете поле TotalSum в t_invoice и при любом добавлении/изменении/удалении записи из t_order просто ее пересчитываете в after триггере на for each statement. Я правда не понял, почему Вы хотите править t_order с отключенными триггерами, но всегда можно сделать глобальную процедуру пересчета итоговых сумм, которая заново рассчитает все итоговые суммы в t_invoice, если они не совпадают с t_order.

Как видите из любой ситуации может быть много выходов. Но в РСУБД лучше помнить, что самый красивый по коду и легкий по реализации выход может оказаться на самом деле с точки зрения РСУБД самым кривым и тормознутым. Я бы Вам порекомендовал не пытаться облегчить жизнь себе, как программисту, а в первую очередь думать о самой СУБД, чтобы было удобно ей. Иначе нарветесь на кучу неприятностей. На это я насмотрелся предостаточно, консультируя людей по их БД, которые при больших обьемах данных просто останавливались, повергая их разработчиков в шок, как оказывается они ошибались, используя навороченные запросы, повторно используемый код, оформленный в виде ХП и UDF, структуру таблиц в виде деревьев и т.д. Причем пока данных было мало все работало как часы - быстро и красиво.