openxml 比 nodes() 慢得多，因其基于游标、需预加载内存、无法并行且不走索引；而 nodes() 是原生流式解析，支持谓词下推、索引优化和查询计划参与。
OPENXML 为什么比 nodes() 慢得多
因为 OPENXML 是基于游标的 XML 解析机制，必须先调用 sp_xml_preparedocument 把 XML 加载进内存缓存，再通过句柄查，整个过程无法并行、不能下推谓词、不走索引优化。而 nodes() 是原生 XML 方法，直接在 XML 类型列上做流式拆解，SQL Server 查询优化器能参与计划生成，支持早期过滤和嵌套循环连接优化。
常见错误现象：sp_xml_preparedocument 返回句柄后忘记调用 sp_xml_removedocument，导致内存泄漏；或在循环中反复 prepare/remove，性能雪崩。
- 使用场景：OPENXML 适合一次解析、多次查询同一份大 XML 的老式存储过程逻辑；
nodes()适合 OLTP 场景下按需提取字段、配合 WHERE 条件过滤 - 参数差异：
OPENXML需显式指定映射模式（1= attribute-centric，2= element-centric），错配会导致空结果；nodes()的 XPath 表达式不支持命名空间前缀缩写，除非用WITH XMLNAMESPACES显式声明 - 性能影响：对 10MB XML 文档，OPENXML 解析耗时通常比
nodes()高 3–8 倍；若 XML 列上有主 XML 索引，nodes()可命中索引，OPENXML 完全无视
nodes() 写法里最容易漏掉的三件事
不是语法报错，而是查不到数据或查得慢——根本原因常藏在 XPath 路径、命名空间和类型转换里。
常见错误现象：XPath 写成 /root/item 却返回空，实际 XML 是 <?xml version="1.0"?><root xmlns="http://example.com">...</root>；或者 value() 返回 NULL，因为没加 [1] 或类型不匹配。
- 必须用
WITH XMLNAMESPACES声明默认命名空间，否则nodes('/root/item')匹配失败 -
nodes()返回的是节点集，每个节点需用value()提取值，且value()第二个参数是 SQL 类型（如'int'），不是 XSD 类型 - 如果路径可能为空，
value('(./@id)[1]', 'int')比value('./@id', 'int')更安全，避免因缺失属性触发 NULL 传播
XML 索引对 nodes() 有效，但对 OPENXML 无效
SQL Server 的主 XML 索引（PRIMARY XML INDEX）只加速原生 XML 方法，包括 nodes()、value()、query()；OPENXML 绕过 XML 引擎，直接操作内部树结构缓存，索引完全不生效。
采用C#.NET,多层架构开发，后台采用大型MS SQL SERVER 数据库和存储过程,速度、性能更胜一筹，网站分为企业和个人会员。企业会员可以发布职位信息，查询人才；个人会员可以发布简历，查询职位。 Build 1228更新： 企业会员可以对个人发送面试通知,个人会员可以收藏企业发布的招聘职位
使用场景：如果你的表有高频 XML 字段查询（比如日志解析、配置读取），且 XML 结构稳定，建主 XML 索引 + nodes() 是唯一可行的高性能路径。
- 建索引前确认 XML 列是
XML类型（不是NVARCHAR(MAX)），否则报错The primary XML index must be created on a column of type 'xml' - 主 XML 索引本身不压缩数据，会增加约 2–3 倍存储开销；次级 XML 索引（如
PATH）才能加速nodes()中的路径查找 - ALTER TABLE 添加 XML 索引会锁表，生产环境建议在低峰期执行
什么时候还不得不选 OPENXML
只有两种情况：需要把 XML 映射成非关系结构（比如动态列名）、或必须复用遗留存储过程里已有的 OPENXML 句柄逻辑。除此之外，没有正当理由选它。
常见错误现象：试图用 OPENXML 解析超过 50MB 的 XML，触发 sp_xml_preparedocument 的内存限制（默认最大约 400MB，但实际受 max server memory 和执行上下文影响很大），报错 Could not allocate enough memory for the XML document。
- 如果 XML 来自外部系统且结构多变，优先考虑在应用层解析（如 C# 的
XDocument或 Python 的lxml），别硬塞进 SQL Server - OPENXML 不支持 XQuery，无法做复杂条件筛选（比如
sum()、contains()），所有计算都得靠后续 T-SQL 处理，容易写出低效嵌套子查询 - SQL Server 2022 开始，
nodes()已支持FOR JSON直出，而 OPENXML 输出只能是表变量/临时表，链路更长
XML 查询真正的瓶颈往往不在方法选择，而在是否让 XML 承担了本该由关系模型处理的职责——比如把订单明细存成 XML 而不是子表，再怎么优化 nodes() 也难逃反范式代价。
