как вы указали, что результаты (таблицы) udf не будут ни к чему присоединены, тогда это не повлияет на производительность.
Чтобы попытаться немного объяснить, почему пользовательские функции могут восприниматься как медленные (на самом деле они просто используются неправильно), рассмотрим следующий пример.
У нас есть таблица A и таблица B. Скажем, у нас было соединение вроде
ВЫБЕРИТЕ A.col1, A.col2, B.ColWhatever FROM A JOIN B ON A.aid = b.fk_aid WHERE B.someCol = @param1 AND A.anotherCol = @param2
В этом случае SQL Server сделает все возможное, чтобы вернуть результаты наиболее эффективным из известных ему способов. Основным фактором в этом является сокращение операций чтения с диска. Итак, он будет использовать условия в предложении JOIN и where для оценки (надеюсь, с индексом), сколько строк нужно вернуть.
Теперь предположим, что мы извлекаем некоторую часть условий, используемых для ограничения количества данных, возвращаемых в UDF. Теперь оптимизатор запросов больше не может вытягивать минимальное количество строк с диска, он может работать только с теми условиями, которые он предоставляет. В двух словах - таблица udf всегда оценивается, и данные возвращаются до того, как они будут возвращены в основную sproc, поэтому, если в исходном соединении были какие-то другие критерии, которые могли вызвать меньшее количество операций чтения с диска - это будет применяться только к данным после втягивания в sproc.
Итак, скажем, мы создаем UDF для выбора строк из таблицы B, которые соответствуют предложению where. Если в таблице B 100 тыс. строк и 50% из них соответствуют критериям предложения where, то все эти строки будут возвращены в sproc для сравнения с таблицей A. Теперь, если только 10% из них имеют совпадения в таблице A сейчас мы говорим только о 5% таблицы B, с которыми мы хотим работать, но мы уже убрали 50%, большинство из которых нам не нужно!
Если это покажется полной тарабарщиной извинений - пожалуйста, дайте мне знать!
person
Community
schedule
03.07.2009
