为什么 VALUES(CONVERT(XML,'...')) 比 VALUES(@xml) 慢得多？

Question

我想创建一个子查询，它生成一个数字列表作为单列结果，类似于 MindLoggedOut did here 但没有 @x xml 变量，因此它可以作为不带 sql 参数的纯字符串（子查询）附加到 WHERE 表达式。问题是参数（或变量）的替换使查询运行慢了5000倍，我不明白为什么。是什么造成了如此大的差异？

示例：

/* Create a minimalistic xml like <b><a>78</a><a>91</a>...</b> */
DECLARE @p_str VARCHAR(MAX) =
    '78 91 01 12 34 56 78 91 01 12 34 56 78 91 01 12 34 56';
DECLARE @p_xml XML = CONVERT(XML,
  '<b><a>'+REPLACE(@p_str,' ','</a><a>')+'</a></b>'
);

SELECT a.value('(child::text())[1]','INT')
FROM (VALUES (@p_xml)) AS t(x)
CROSS APPLY x.nodes('//a') AS x(a);

这 returns 每行一个数字，速度非常快（比我目前使用的字符串拆分器方法 similar to these 快 20 倍）。我根据 sql 服务器 CPU 时间测量了 20 倍的加速，其中 @p_str 包含 3000 个数字。）

现在，如果我将 @p_xml 的定义内联到查询中：

SELECT a.value('(child::text())[1]','INT')
FROM (VALUES (CONVERT(XML,
  '<b><a>'+REPLACE(@p_str,' ','</a><a>')+'</a></b>'
))) AS t(x)
CROSS APPLY x.nodes('//a') AS x(a);

然后它变得慢了 5000 倍（当 @p_str 包含数千个数字时。）查看查询计划我找不到原因。

first query (…VALUES(@p_xml)…), and the second (…VALUES(CONVERT(XML,'...'))…)

计划

有人可以解释一下吗？

更新

显然第一个查询的计划不包括成本 @p_xml = CONVERT(XML, ...REPLACE(...)... ) 作业的，但是这个成本不是可以解释 46 毫秒与 234 秒的罪魁祸首整个脚本的执行时间之间的差异（当 @p_str 很大）。这种差异是系统性的（不是随机的）实际上在 SqlAzure（S1 层）中观察到。

此外，当我重写查询时：用用户定义的标量函数替换 CONVERT(XML,...)：

SELECT a.value('(child::text())[1]','INT')
FROM (VALUES (dbo.MyConvertToXmlFunc(
  '<b><a>'+REPLACE(@p_str,' ','</a><a>')+'</a></b>'
))) AS t(x)
CROSS APPLY x.nodes('//a') AS x(a);

其中 dbo.MyConvertToXmlFunc() 是：

CREATE FUNCTION dbo.MyConvertToXmlFunc(@p_str NVARCHAR(MAX))
RETURNS XML BEGIN
  RETURN CONVERT(XML, @p_str);
END;

差异消失了 (plan)。所以至少我有一个解决方法......但想了解它。

Answer 1

这与 this answer by Paul White 中描述的问题基本相同。

我尝试使用长度为 10,745 个字符的字符串，其中包含 3,582 个项目。

带有字符串文字的执行计划最终执行字符串替换并将整个字符串转换为每个项目两次 XML（总共 7,164 次）。

有问题的 sqltses.dll!CEsExec::GeneralEval4 调用在下面的跟踪中突出显示。整个调用堆栈的 CPU 时间为 22.38%（几乎用尽了四核上的单核）。 - 其中 92% 是通过这两个电话完成的。

在每次调用中，sqltses.dll!ConvertFromStringTypesAndXmlToXml 和 sqltses.dll!BhReplaceBhStrStr 花费的时间几乎相等。

我在下面的计划中使用了相同的颜色编码。

执行计划的底部分支对字符串中的每个拆分项执行一次。

右下角有问题的 table 值函数在其 open 方法中。该函数的参数列表是

Scalar Operator([Expr1000]),

Scalar Operator((7)),

Scalar Operator(XML Reader with XPath filter.[id]),

Scalar Operator(getdescendantlimit(XML Reader with XPath filter.[id]))

对于 Stream Aggregate，问题出在它的 getrow 方法中。

[Expr1010] = Scalar Operator(MIN(
SELECT CASE
         WHEN [Expr1000] IS NULL
           THEN NULL
         ELSE
           CASE
             WHEN datalength([XML Reader with XPath filter].[value]) >= ( 128 )
               THEN CONVERT_IMPLICIT(int, [XML Reader with XPath filter].[lvalue], 0)
             ELSE CONVERT_IMPLICIT(int, [XML Reader with XPath filter].[value], 0)
           END
       END 
))

这两个表达式都引用 Expr1000（尽管流聚合这样做只是为了检查它是否是 NULL）

右上角常量扫描定义如下

(Scalar Operator(CONVERT(xml,'<b><a>'+replace([@p_str],' '
,CONVERT_IMPLICIT(varchar(max),'</a><a>',0))+'</a></b>',0)))

从跟踪中可以清楚地看出，该问题与之前链接的答案中的问题相同，并且在缓慢的计划中反复重新评估。当作为参数传递时，昂贵的计算只发生一次。

编辑：我刚刚意识到这实际上与 Paul White 几乎完全相同的计划和问题 blogged about here - 我的测试与那里描述的唯一区别是我找到了字符串 Replace 和XML 转换在 VARCHAR(MAX) 情况下彼此一样糟糕 - 并且字符串替换在非最大情况下超过转换成本。

最大

非最大

（2000 个字符源字符串，668 个项目。替换后 6010 个字符）

在此测试中，替换几乎是 CPU 转换成本的两倍 xml。它似乎是通过使用来自熟悉的 TSQL 函数 CHARINDEX 和 STUFF 的代码来实现的，并且花费了大量时间将字符串转换为 unicode。我认为我的结果与 Paul 报告的结果之间的这种差异归结为整理（从 Latin1_General_CS_AS 切换到 SQL_Latin1_General_CP1_CS_AS 显着降低了字符串替换的成本）

为什么 VALUES(CONVERT(XML,'...')) 比 VALUES(@xml) 慢得多？

Why is VALUES(CONVERT(XML,'...')) much slower than VALUES(@xml)?

xml

sql-server

performance

sql-execution-plan

最大

非最大