应优先使用.nodes()和.value()替代openxml，因其支持xml索引、避免内存泄漏且性能更优；.nodes()需指定元素路径，.value()须带[1]并用text()取值；where中应先用.exist()预筛再.value()提取，且必须先建主xml索引才能生效。
直接用 .nodes() + .value()，别碰 OPENXML
SQL Server 2005 以后，OPENXML 就该进历史了。它要显式调用 sp_xml_preparedocument 和 sp_xml_removedocument，手抖漏掉后者会导致内存泄漏；而且整个过程是基于临时内存树的，无法利用 XML 索引，性能差、并发低。
现代写法直接用原生 XML 方法：.nodes() 把 XML 拆成行集，再用 .value() 提取字段。它走的是引擎内置解析器，支持 XML 索引下推，还能被查询优化器估算行数。
-
@xml.nodes('/root/item')路径必须返回元素节点（不能是文本或属性），否则返回空结果集 - 每个
.value()必须带[1]，否则报错“XQuery [value()]: ‘value()’ requires a singleton (or empty sequence)” - 路径里用
text()显式取文本值，比如'(name/text())[1]'，不加会返回带标签的 XML 片段，类型不匹配 - 如果某节点可能为空，
.value()返回 NULL，不用额外 try-catch —— 但别在 WHERE 里直接写.value() > 10，这没法走索引
WHERE 条件里优先用 .exist() 预筛，再用 .value() 提取
查 XML 字段时，最常见性能陷阱就是把 .value() 放在 WHERE 里做比较：例如 WHERE content.value('(/book/price)[1]', 'DECIMAL') > 49.9。这会导致全表扫描，因为函数包裹列无法命中任何索引。
正确做法是分两步：先用 .exist() 快速过滤出含目标路径的行（可走 PATH 索引），再在结果集里用 .value() 精确提取值。
-
WHERE content.exist('/book[price > 49.9]') = 1—— 注意 XPath 中不能直接写>，得用实体编码>，SQL Server 不支持原生比较符 - 若需参数化，用
sql:variable("@minPrice")，如content.exist('/book[price > sql:variable("@minPrice")]') -
.exist()返回 NULL 当 XML 列为 NULL，所以实际条件建议写成IS NOT NULL AND ... = 1更稳妥
建 XML 索引前，必须先建主 XML 索引
想让 .exist()、.value() 或 .query() 走索引，不是直接建个次级索引就行。XML 索引是分层结构：主索引（PRIMARY）是聚集索引，把 XML 内部节点展开成系统表；所有次级索引（PATH/VALUE/PROPERTY）都依赖它存在。
漏建主索引，或者主索引被禁用，次级索引就形同虚设——执行计划里照样显示“Table Scan”。
- 主索引语法：
CREATE PRIMARY XML INDEX IX_primary ON docs(content) - PATH 索引加速路径查找（如
/book/title），适合.exist()和带明确路径的.value() - VALUE 索引加速通配查找（如
//price），适合模糊路径或深层嵌套场景 - 一个 XML 列上最多建一个主索引、三个次级索引；索引本身占空间大、写入开销高，只对高频查询字段建
类型化 XML 能省掉部分类型转换，但别指望它自动提速
如果你的数据结构稳定、有 XSD 定义，注册 Schema Collection 并绑定到 XML 列，就能启用类型化 XML。它的价值主要在两点：一是插入时强校验，坏数据拦在门外；二是 .value() 中某些类型可省略声明，比如 xs:integer 属性能自动映射为 SQL INT。
但它不会让查询变快——索引行为、执行计划、IO 开销和非类型化 XML 完全一致。类型信息只影响解析阶段的类型推断，不改变底层存储结构或索引机制。
- 非类型化 XML 所有值默认按字符串处理，
.value('(@id)', 'INT')必须显式指定类型，否则报错 - 类型化 XML 中，若 XSD 已声明
@id为xs:integer，可简写为.value('(@id)', 'INT')或甚至.value('(@id)')（引擎尝试推断） - XSD 解析本身有 CPU 开销，写入吞吐量比非类型化低 10%~20%，日志类、配置类数据没必要上类型化
/a/b/c 有效，对 //c 无效；VALUE 索引对 //c 有效，但对 /a/b/c 效率反而不如 PATH。路径写法、索引选型、是否类型化，得按实际查询模式一条条对齐，没法一劳永逸。
