应使用XML类型而非NVARCHAR(MAX)接收XML入参：前者在传入时即校验格式并即时报错，后者延迟至.nodes()或.value()调用时才爆错且定位困难；XML类型还支持XML索引优化查询性能，而NVARCHAR(MAX)不支持。
XML入参该用XML类型，别用NVARCHAR(MAX)
直接把XML当字符串传进来，看似简单，实则埋雷。SQL Server不会自动验证格式，NVARCHAR(MAX)里混入非法字符、编码错误或未闭合标签，到真正调用.value()或.nodes()时才爆错，且错误信息模糊（比如“XML parsing: line X, character Y, unexpected end of input”），定位成本高。而声明为XML类型参数，SQL Server会在传入瞬间做基础解析校验——格式不对直接报错，不进存储过程体，省去后续层层排查。
实操建议：
- 存储过程定义中明确写
@xmlData XML，不是@xmlData NVARCHAR(MAX) - 应用层传入前确保UTF-16编码（SQL Server内部使用），避免BOM头或乱码导致解析失败
- 若XML来自外部系统（如老VFP或Java Axis），先用
TRY_CAST(@input AS XML)兜底，失败则返回友好错误，而不是让整个过程崩溃
.nodes()必须配CROSS APPLY，路径写错=静默丢数据
.nodes()不是万能展开器，它对XPath极其敏感：大小写、命名空间、层级遗漏一个字符，就返回空结果集。更危险的是，CROSS APPLY遇到空结果会直接过滤掉原行——你查不到数据，但根本看不出是XML路径错了，还是业务上真没这条记录。
常见错误现象：
- 存储过程逻辑看似完整，但某些输入XML下查询结果为空，日志无报错
- WHERE条件里用了
xmlCol.exist('/Root/Item')，却因实际XML是<root><item>...（小写）而失效，触发全表扫描
实操建议：
- 路径严格匹配源XML：用
.exist()先探路，例如IF @xmlData.exist('/Items/Item') = 0 RAISERROR('Missing /Items/Item path', 16, 1) - 命名空间必须显式声明：若XML含
xmlns="http://abc"，XPath得写WITH XMLNAMESPACES(DEFAULT 'http://abc') SELECT ... .nodes('/Items/Item') AS T(C) - 避免
[1]硬截断，要取全部节点就写/Items/Item，别写/Items/Item[1]
.value()强转失败直接中断，别信默认类型推导
.value('(/Item/@id)[1]', 'INT')看着没问题，但如果XML里@id是空字符串、非数字字符，或字段根本不存在，SQL Server不返回NULL，而是抛出“XQuery [value()]: ‘value()’ requires a singleton (or empty sequence)”这类晦涩错误，尤其在UPDATE或事务中，容易掩盖真实业务逻辑问题。
实操建议：
- 数值类一律用
TRY_CAST(... AS INT)包裹：TRY_CAST(T.c.value('(@amount)[1]', 'NVARCHAR(20)') AS DECIMAL(18,2)) - 字符串字段加
ISNULL(..., '')，防止后续CONCAT或拼接时整列变NULL - 属性取值必须带
@前缀：@id[1]，写成id[1]永远返回NULL - 文本内容用
(Name/text())[1]，不是Name[1]——后者可能匹配到元素节点而非文本节点
大XML不建索引，.exist()和.value()就是定时炸弹
如果XML字段高频参与查询（比如按/Order/Status筛选订单），又没建XML索引，每次执行.exist()或.value()都会触发全列XML重新解析。10万行数据，单次查询可能从200ms飙到5秒以上，且IO和CPU压力陡增。
实操建议：
- 必须建主XML索引：
CREATE PRIMARY XML INDEX IX_XML_ProductDetails ON ProductCatalog(ProductDetails) - 再按高频查询路径建次级索引，例如常查
/Product/Features/Feature[@Name]，就建CREATE XML INDEX IX_XML_FeatureName ON ProductCatalog(ProductDetails) USING XML INDEX IX_XML_ProductDetails FOR PATH - 索引只对
XML类型列有效，对NVARCHAR(MAX)列无效——再次强调别用字符串存XML - 索引维护有成本，若XML极少查询、只用于归档，可不建；但只要出现在WHERE或JOIN条件里，就必须建
真正卡住性能的，往往不是XPath写得有多复杂，而是忘了XML索引这道门槛。路径写错顶多查不到数据，索引缺失会让整个表慢得无法接受——而且这种慢会随着数据量线性增长，上线初期看不出来，半年后突然崩盘。
