Достаточно хорошо задокументировано, что UDF определяют общий последовательный план.
Я не уверен, что все это хорошо задокументировано.
- Скалярная функция T-SQL предотвращает параллелизм в любом месте плана.
- Скалярная функция CLR может выполняться параллельно, если она не имеет доступа к базе данных.
- Табличнозначная функция T-SQL с несколькими утверждениями вынуждает последовательную зону в плане, которая может использовать параллелизм в другом месте.
- Встроенная табличная функция T-SQL расширяется как представление, поэтому не имеет прямого эффекта.
См. Форсирование плана параллельного выполнения и / или презентацию Крейга Фридмана о параллельном выполнении .
Есть заявления о том, что UDF должны быть в черном ящике с курсором.
Эти претензии не верны.
Дополнительные баллы за объяснение того, почему двигатель заставляет весь план быть последовательным, а не только этап расчета UDF.
Насколько я понимаю, текущие ограничения являются чисто результатом некоторых деталей реализации. Нет фундаментальной причины, по которой функции не могут быть выполнены с использованием параллелизма.
В частности, скалярные функции T-SQL выполняются в отдельном контексте T-SQL, что значительно усложняет правильную работу, координацию и завершение работы (особенно в случае ошибки).
Точно так же переменные таблицы поддерживают параллельное чтение (но не запись) в целом, но табличная переменная, предоставляемая табличной функцией, не может поддерживать параллельное чтение по причинам, связанным с реализацией. Я боюсь, что вам нужен кто-то с доступом к исходному коду (и свободой для обмена подробностями), чтобы дать авторитетный ответ.
Является ли поддержка параллельной UDF разумной функцией для запроса?
Конечно, если вы можете сделать достаточно сильный аргумент. Я считаю, что работа будет обширной, поэтому ваше предложение должно соответствовать чрезвычайно высокой планке. Например, связанный (и гораздо более простой) запрос на предоставление встроенных скалярных функций имеет большую поддержку, но уже несколько лет томится невыполненным.
Вы можете прочитать статью Microsoft:
... который описывает подход, который Microsoft использует для решения проблем производительности скалярных функций T-SQL в выпуске после SQL Server 2017.
Цель Froid - дать разработчикам возможность использовать абстракции пользовательских функций и процедур без ущерба для производительности. Фройд достигает этой цели, используя новую технику для автоматического преобразования императивных программ в эквивалентные алгебраические формы отношений, когда это возможно. Froid моделирует блоки императивного кода как реляционные выражения и систематически объединяет их в одно выражение с помощью оператора Apply, что позволяет оптимизатору запросов выбирать эффективные ориентированные на множество параллельные планы запросов.
(акцент мой)
Встроенные скалярные функции T-SQL теперь реализованы в SQL Server 2019 .