crokusek Asked: 2014-07-25 13:43:06 +0800 CST2014-07-25 13:43:06 +0800 CST 2014-07-25 13:43:06 +0800 CST 对并行标量 UDF 的支持是合理的功能要求吗？ 772 标量 UDF 强制执行整体串行计划，这是相当有据可查的。 并行运行函数 鉴于大量行进入管道中必须计算 UDF 的点，为什么引擎不能在处理器之间分配它们？如果 UDF 中没有状态，则顺序无关紧要。 有人声称 UDF 是一个必须使用光标的黑盒。我可以看到，对于在迭代之间保持某些状态但似乎应该是可并行化的情况，用户光标无法在 SP 内并行化。 额外的点来解释为什么引擎强制整个计划是串行的，而不仅仅是 UDF 计算阶段。 对并行 UDF 的支持是否是一个合理的请求功能？ sql-server parallelism 2 个回答 Voted Best Answer Paul White 2014-07-25T14:29:52+08:002014-07-25T14:29:52+08:00 UDF 强制执行整体串行计划是相当有据可查的。 我不确定它是否有据可查。 标量 T-SQL 函数可防止计划中任何地方的并行性。 只要不访问数据库，标量 CLR 函数就可以并行执行。 多语句表值 T-SQL 函数在计划中强制使用串行区域，该计划可能在其他地方使用并行性。 内联表值 T-SQL 函数像视图一样展开，因此没有直接影响。 请参阅强制执行并行执行计划和/或 Craig Freedman 的并行执行演示文稿。 有人声称 UDF 是一个黑盒，必须使用光标。 这些说法是不正确的。 额外的点来解释为什么引擎强制整个计划是串行的，而不仅仅是 UDF 计算阶段。 我的理解是，当前的限制纯粹是某些实施细节的结果。没有根本原因无法使用并行性执行函数。 具体来说，T-SQL 标量函数在单独的 T-SQL 上下文中执行，这使正确操作、协调和关闭（尤其是在发生错误的情况下）变得非常复杂。 同样，表变量通常支持并行读取（但不支持写入），但表值函数公开的表变量由于特定于实现的原因不能支持并行读取。恐怕你需要有源代码访问权限（以及分享细节的自由）的人来提供权威的答案。 对并行 UDF 的支持是否是一个合理的请求功能？ 当然，如果你能做一个足够强大的案例。我自己的感觉是，所涉及的工作会很广泛，所以你的提案必须达到一个非常高的标准。例如，提供内联标量函数的相关（并且更简单）的请求得到了很好的支持，但多年来一直没有实现。 您可能想阅读 Microsoft 论文： Froid：关系数据库中命令式程序的优化(pdf) ...它概述了 Microsoft 希望在 SQL Server 2017 之后的版本中解决 T-SQL 标量函数性能问题的方法。 Froid 的目标是使开发人员能够在不影响性能的情况下使用 UDF 和过程的抽象。Froid 使用一种新技术来实现这一目标，尽可能将命令式程序自动转换为等效的关系代数形式。Froid 将命令式代码块建模为关系表达式，并使用 Apply 运算符系统地将它们组合成一个表达式，从而使查询优化器能够选择有效的面向集合的并行查询计划。 （强调我的） 内联标量 T-SQL 函数现在在 SQL Server 2019 中实现。 Karthik 2018-02-10T12:53:53+08:002018-02-10T12:53:53+08:00 正如保罗在他的回答中正确提到的那样，没有根本原因不能使用并行执行标量 UDF。然而，除了实现方面的挑战之外，还有另一个原因迫使它们串行化。Paul 引用的Froid论文提供了更多相关信息。 引用论文（第 2.3 节）： 目前，SQL Server 在调用 UDF 的查询中不使用查询内并行性。可以设计方法来减轻这种限制，但它们会带来额外的挑战，例如为 UDF 的每次调用选择正确的并行度。 例如，考虑一个调用其他 SQL 查询的 UDF，如图 1 中的那个。每个这样的查询本身可能使用并行性，因此，优化器无法知道如何在它们之间共享线程，除非它查看UDF 并决定其中每个查询的并行度（可能会从一个调用更改为另一个）。使用嵌套和递归 UDF，这个问题变得更加难以管理。 如论文所述，Froid 的方法不仅会产生并行计划，还会为使用 UDF 的查询增加更多好处。本质上，它包含了您对 UDF 并行执行的请求。 更新： Froid 现在作为 SQL Server 2019 预览版的一项功能提供。该功能称为“标量 UDF 内联”。更多详细信息：https ://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/11/07/introducing-scalar-udf-inlining/ [披露：我是 Froid 论文的合著者]
我不确定它是否有据可查。
请参阅强制执行并行执行计划和/或 Craig Freedman 的并行执行演示文稿。
这些说法是不正确的。
我的理解是，当前的限制纯粹是某些实施细节的结果。没有根本原因无法使用并行性执行函数。
具体来说，T-SQL 标量函数在单独的 T-SQL 上下文中执行，这使正确操作、协调和关闭（尤其是在发生错误的情况下）变得非常复杂。
同样，表变量通常支持并行读取（但不支持写入），但表值函数公开的表变量由于特定于实现的原因不能支持并行读取。恐怕你需要有源代码访问权限（以及分享细节的自由）的人来提供权威的答案。
当然，如果你能做一个足够强大的案例。我自己的感觉是，所涉及的工作会很广泛，所以你的提案必须达到一个非常高的标准。例如，提供内联标量函数的相关（并且更简单）的请求得到了很好的支持，但多年来一直没有实现。
您可能想阅读 Microsoft 论文：
...它概述了 Microsoft 希望在 SQL Server 2017 之后的版本中解决 T-SQL 标量函数性能问题的方法。
（强调我的）
内联标量 T-SQL 函数现在在 SQL Server 2019 中实现。
正如保罗在他的回答中正确提到的那样，没有根本原因不能使用并行执行标量 UDF。然而，除了实现方面的挑战之外，还有另一个原因迫使它们串行化。Paul 引用的Froid论文提供了更多相关信息。
引用论文（第 2.3 节）：
如论文所述，Froid 的方法不仅会产生并行计划，还会为使用 UDF 的查询增加更多好处。本质上，它包含了您对 UDF 并行执行的请求。
[披露：我是 Froid 论文的合著者]