sql-server – 有没有办法阻止计算列中的标量UDF抑制并行性？

关于sql Server中的 perils of Scalar UDFs已经写了很多.随意搜索将返回大量结果.

但是,有些地方标量UDF是唯一的选择.

例如：处理XML时：XQuery不能用作计算列定义. Microsoft记录的一个选项是使用Scalar UDF将XQuery封装在Scalar UDF中,然后在计算列中使用它.

这有各种影响和一些解决方法.

>查询表时逐行执行
>强制对表的所有查询以串行方式运行

您可以通过架构绑定函数来解决逐行执行问题,并保留计算列或对其进行索引.这些方法都不能阻止强制序列化查询到表中,即使未引用标量UDF也是如此.

有没有一种已知的方法可以做到这一点？

解决方法

是的,如果您：

>正在运行sql Server 2014或更高版本;和
>能够以跟踪标志176激活的方式运行查询;和
>计算列是PERSISTED

具体来说,至少以下版本为are required：

> sql Server 2016 SP1的累积更新2
> sql Server 2016 RTM的累积更新4
> sql Server 2014 SP2的累积更新6

但是要避免在这些修复中引入的错误(参考2014和2016 and 2017),而是应用：

> Cumulative Update 1 for SQL Server 2017
> Cumulative Update 5 for SQL Server 2016 SP1
> Cumulative Update 8 for SQL Server 2016 RTM
> Cumulative Update 8 for SQL Server 2014 SP2

跟踪标志在使用DBCC TRACEON的全局和会话范围以及使用OPTION(QUERYTRACEON)或计划指南的每个查询中作为启动-T选项有效.

跟踪标志176防止持久计算列扩展.

编译查询时执行的初始元数据加载会引入所有列,而不仅仅是直接引用的列.这使得所有计算列定义都可用于匹配,这通常是一件好事.

作为一个不幸的副作用,如果其中一个加载(计算)列使用标量用户定义函数,则其存在会禁用整个查询的并行性,即使实际未使用计算列也是如此.

如果列是持久的,则跟踪标志176通过不加载定义(因为跳过扩展)来帮助解决此问题.这样,标量用户定义的函数永远不会出现在编译查询树中,因此不会禁用并行性.

跟踪标志176的主要缺点(除了仅仅是轻微记录)是它还防止查询表达式匹配到持久计算列：如果查询包含与持久计算列匹配的表达式,则跟踪标志176将阻止表达式被替换为对计算列的引用.

有关更多详细信息,请参阅我的sqlPerformance.com文章Properly Persisted Computed Columns.

由于问题提到了XML,作为使用计算列和标量函数来提升值的替代方法,您还可以查看使用选择性XML索引,如您在Selective XML Indexes: Not Bad At All中所述.