sql-server - 为什么 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);

这每行返回一个数字并且速度非常快(比我目前使用的字符串拆分器方法快 20 倍，similar to these。 我根据 sql server 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 时，两者花费的时间几乎相同。

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

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

右下角有问题的表值函数在其 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 个字符)

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