nodes()必须配合CROSS APPLY或OUTER APPLY使用，因其仅生成含xml类型列的虚拟行集而非真实表；直接SELECT FROM @xml.nodes()会报错，XPath区分大小写且需精确匹配，无匹配时返回空结果集。
nodes() 必须配合 CROSS APPLY 才能用
直接写 SELECT * FROM @xml.nodes('/root/item') 会报错，因为 nodes() 不返回表，只生成一个带 XML 类型列的虚拟行集。它必须“挂”在已有数据源上才能访问。
常见写法是：CROSS APPLY @xml.nodes('/root/item') AS T(c)，其中 T 是别名表名，c 是每行对应的节点引用。后续所有 value() 都基于 c 调用。
-
CROSS APPLY：原数据中某行没匹配到节点，整行被过滤掉 -
OUTER APPLY：原数据行保留，未匹配时对应字段为NULL - 路径区分大小写，
/Root/Item和/root/item是两个不同路径 - 路径无匹配时，
nodes()返回空结果集（不是报错），容易误判为“XML为空”
value() 提取值总返回 NULL？先看这四个硬性条件
value() 是强契约式提取：XPath 必须返回且仅返回一个原子值（或空），否则静默 NULL 或直接报错。它不宽容、不猜测，只认规则。
- 忘了加
[1]：哪怕路径只可能命中一个节点，也必须写(Name/text())[1]；写成Name/text()会报错XQuery [value()]: 'value()' requires a singleton - 该取文本却没写
text()：比如value('Name', 'NVARCHAR(50)')返回的是整个<name>Apple</name>片段，不是字符串"Apple"；正确写法是value('(Name/text())[1]', 'NVARCHAR(50)') - 取属性漏了
@：写value('id', 'INT')是错的，必须是value('(@id)[1]', 'INT') - 类型强转失败：对空字符串或非数字内容做
value('.', 'INT')，直接返回NULL；建议改用TRY_CAST(c.value('(./@id)[1]', 'NVARCHAR(20)') AS INT)
XML 带命名空间时 nodes() 为啥总查不到节点
只要 XML 根节点声明了 xmlns="http://xxx"（哪怕没前缀），nodes('/Root/Item') 就永远匹配失败——SQL Server 默认不识别默认命名空间。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
必须在查询前显式绑定：
- 用默认命名空间：
WITH XMLNAMESPACES (DEFAULT 'http://xxx')，然后路径写成/Root/Item - 用带前缀方式：
WITH XMLNAMESPACES ('http://xxx' AS ns)，然后路径写成/ns:Root/ns:Item - 验证是否生效：
@xml.exist('declare namespace x="http://xxx"; /x:Root')返回1表示可识别
注意：命名空间声明必须放在整个查询最前面，不能嵌套在子查询里。
把 XML 字段和物理表 JOIN 时性能突然变差
核心问题是 nodes() 生成的中间结果集没有统计信息、无法走索引。每次执行都会触发全量 XML 解析 + 节点展开，如果 XML 存在大表中且没加前置过滤，实际就是全表扫描 + 逐行解析。
- 避免在大表上无条件使用
CROSS APPLY ... nodes() - 先用
exist()在WHERE中快速过滤掉不含目标节点的行：WHERE OrderXML.exist('/Order/Items/Item') = 1 -
exist()可利用 XML 索引（如果建了），而value()+ 函数组合通常不能 - 若需高频解析，考虑将关键字段提前解出并持久化到普通列，而非每次运行时动态解析
命名空间处理、[1] 强制索引、APPLY 类型选择——这三个地方写错一个，结果就可能全空或全 NULL，而且不会报错，只默默返回错误数据。
