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 引擎，直接操作内部树结构缓存，索引完全不生效。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
使用场景：如果你的表有高频 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() 也难逃反范式代价。
