主页 / dba / 问题 / 338263
Accepted
Erik Darling
Asked: 2024-04-03 03:05:09 +0800 CST

XML 查询不断将 < 转换为 < 和 > 到 >

  • 772

大XML4u

某些查询计划太大而无法正确存储为 XML。您收到错误：XML datatype instance has too many levels of nested nodes. Maximum allowed depth is 128 levels.

这很好。一切都需要限制以防止滥用。谁知道 129 层嵌套会发生什么。

当然，对于查询计划，您可以将文本格式的 XML 保存为 .sqlplan 文件，然后将其作为图形执行计划重新打开。

我的查询遇到的问题是，当我尝试显示该查询时，<已更改为&lt;和。不幸的是，这在您将文件保存为有效的 .sqlplan（可以重新打开）之前增加了两个额外的步骤。>&gt;

现在，我的查询执行以下操作：

    query_plan = 
         CASE
             WHEN TRY_CAST(qsp.query_plan AS XML) IS NOT NULL
             THEN TRY_CAST(qsp.query_plan AS XML)
             WHEN TRY_CAST(qsp.query_plan AS XML) IS NULL
             THEN 
                 (
                     SELECT
                         (
                             SELECT
                                 N''-- '' + NCHAR(13) + NCHAR(10) +
                                 N''-- This is a huge query plan.'' + NCHAR(13) + NCHAR(10) +
                                 N''-- Remove the headers and footers, save it as a .sqlplan file, and re-open it.'' + NCHAR(13) + NCHAR(10) +
                                 N''-- Depending on local factors, you may need to replace "<" and ">" too.'' + NCHAR(13) + NCHAR(10) +
                                 N''-- '' + NCHAR(13) + NCHAR(10) +
                                 REPLACE(qsp.query_plan, N''<RelOp'', NCHAR(13) + NCHAR(10) + N''<RelOp'') +
                                 NCHAR(13) + NCHAR(10) + N''--'' COLLATE Latin1_General_Bin2 AS [processing-instruction(query_plan)]
                         )
                         FOR XML PATH(N''''), 
                                 TYPE
                 )
         END,

通常，我会遵循自己的建议并将其添加到末尾，但这样做会让我回到有关节点、嵌套和 128 等的原始 XML 错误。

.value
     (
         './text()[1]', 
         'nvarchar(max)'
     );

我尝试添加REPLACE内部和外部选择来尝试修复问题，但该斑点似乎对我的魅力免疫。

有没有办法阻止或规避这些字符的转换，以使保存文件更容易一些？

如果您本地有 StackOverflow 数据库的副本，则可以生成一个查询计划，该计划在 中以 null 结尾TRY_CAST，并且在使用以下查询将其视为 XML 时抛出错误：

WITH
    p0 AS (SELECT pt.* FROM dbo.PostTypes AS pt),
    p1 AS (SELECT pp.* FROM p0 AS p CROSS JOIN p0 AS pp),
    p2 AS (SELECT pp.* FROM p1 AS p CROSS JOIN p1 AS pp),
    p3 AS (SELECT pp.* FROM p2 AS p CROSS JOIN p2 AS pp),
    p4 AS (SELECT pp.* FROM p3 AS p CROSS JOIN p3 AS pp),
    p5 AS (SELECT pp.* FROM p4 AS p CROSS JOIN p4 AS pp),
    p6 AS (SELECT pp.* FROM p5 AS p CROSS JOIN p5 AS pp),
    p7 AS (SELECT pp.* FROM p6 AS p CROSS JOIN p6 AS pp),
    p8 AS (SELECT pp.* FROM p7 AS p CROSS JOIN p7 AS pp),
    p9 AS (SELECT pp.* FROM p8 AS p CROSS JOIN p8 AS pp)
SELECT
    c = COUNT_BIG(*)
FROM p9 AS p
OPTION(RECOMPILE);

如果您只想查看生成的废话，可以使用此 GitHub gist 链接。

sql-server

1 个回答

  1. Best Answer

    您在代码的有问题的部分中执行了一级选择太多。

    您的版本已简化

    select (
       select '<>' as [processing-instruction(query_plan)]
       )
for xml path(''), type;

    结果

    &lt;&gt;

    for xml path直接在处理指令查询上尝试此操作

    select '<>' as [processing-instruction(query_plan)]
for xml path(''), type;

    结果

    <?query_plan <>?>

    解释：

    select '<>' as [processing-instruction(query_plan)]它本身什么也不做，只是返回带有一些看起来奇怪的列名的字符串值。

    当您添加时，for xml path神奇的事情发生了，处理指令成为 xml 的一部分。

    该查询select (select '<>' as [processing-instruction(query_plan)])将返回没有花哨的列名称的字符串值，因此for xml path不会为您创建处理指令。相反，它只是一个被实体化的字符串，因为它应该是有效的 XML。

    • 8

相关问题