SQL Server中XML参数高效用法是合理使用.nodes()配合类型防御，避免OPENXML；.nodes()流式处理快于OPENXML的DOM构建，需注意XPath大小写、路径准确性及XML索引优化。
SQL Server 存储过程中用 XML 做参数或中间数据载体，效率取决于用法，不是“能用”就等于“高效”。盲目传大 XML 或滥用 .value() 会拖慢十倍以上；而合理配合 .nodes() 和类型防御，批量处理 10 万行也能控制在 1 秒内。
XML 参数 vs OPENXML：性能差一倍以上
实测 9 万行数据时：OPENXML（含 sp_xml_preparedocument）平均耗时 16–22 秒；.nodes() + .value() 写法稳定在 8 秒左右。根本原因在于 OPENXML 需要在内存中构建整个 DOM 树并注册句柄，而 .nodes() 是流式节点匹配，不缓存全文。
-
OPENXML必须配对调用sp_xml_removedocument，漏掉会导致句柄泄漏 -
.nodes()不需要显式清理，但 XPath 路径错一个字符就返回空结果，且无报错提示 - VFP 或旧系统生成的 XML（如小写字段名、无命名空间）用
.nodes()更稳，OPENXML的WITH子句对大小写敏感且列名必须小写
.nodes() 路径写错导致查询变全表扫描
.nodes() 返回空行集时，CROSS APPLY 会直接过滤掉原记录 —— 表面看是“没数据”，实际可能是路径写错，进而让外层 JOIN 或 WHERE 失效，触发意外的全表扫描。
- 路径区分大小写：
/Items/Item≠/items/item，XML 源来自 .NETDataSet.GetXml()时默认是diffgram结构，根节点常为diffgr:diffgram - 避免用
[1]截断：如/Items/Item[1]只取第一个节点，漏数据；应写/Items/Item让.nodes()展开全部 - 嵌套层级多时，先用
.exist('/Root/Section[@type="meta"]')判断存在再查值，比硬写.value()更安全
.value() 类型强转失败会让整个语句报错
.value() 对空节点、缺失属性、类型不匹配（比如把空字符串转 INT）不是返回 NULL，而是直接中断执行——尤其在 UPDATE 或事务里，容易被当成逻辑错误掩盖。
- 必加
[1]：写成(Name/text())[1]而非Name/text()，否则多节点时返回错误 - 属性要带
@：取id属性必须写@id[1]，写成id[1]永远 NULL - 数值类优先用
TRY_CAST(T.c.value('(@amount)[1]', 'NVARCHAR(20)') AS DECIMAL(18,2))，别依赖.value('.', 'DECIMAL') - 字符串字段用
ISNULL(..., '')包一层，避免后续拼接时因 NULL 导致整字段变 NULL
真正卡顿的点往往不在 XML 解析本身，而在没建 XML 索引却在 WHERE 里反复用 .exist() 或 .value() —— 这会让 SQL Server 每次都重新解析整列 XML。如果 XML 字段高频参与查询，PRIMARY XML INDEX 和按路径建的 SECONDARY XML INDEX 不是可选项，是必选项。
