SQL Server用OPENXML需显式声明WITH映射并释放句柄；PostgreSQL用xpath()+UNNEST()配合CROSS JOIN LATERAL；MySQL宜转JSON再用JSON_TABLE；三者均不可在WHERE中直接过滤XML字段，应预计算关键字段建索引。
SQL Server 中用 OPENXML 查询 XML 字段并 JOIN 关系表
SQL Server 的 OPENXML 是少数能高效把 XML 内容“展开”成行集的原生方式，但直接和 JOIN 表混用时极易出错——不是数据重复，就是 NULL 值泛滥，或者执行计划突然变慢。
核心问题在于：OPENXML 返回的是临时游标，必须显式释放；而它和普通表 JOIN 时，SQL Server 默认按笛卡尔积逻辑匹配，除非你用 WITH 子句严格绑定字段映射关系。
- 先用
sp_xml_preparedocument解析 XML，拿到文档句柄（@hdoc），这步失败会静默返回 0，别只靠@@ERROR判断，要检查句柄是否非零 -
OPENXML(@hdoc, '/root/item', 2)的第三个参数必须是2（attribute-centric）或1（element-centric），选错会导致所有字段为 NULL；多数业务 XML 是属性型（<item id="1" name="a"/>），就用2 -
JOIN时别写FROM OPENXML(...) AS x JOIN orders o ON x.id = o.order_id—— 这里x.id是未声明的列名，必须在WITH里显式定义类型和路径，比如WITH (id INT '@id', name NVARCHAR(50) '@name') - 用完立刻执行
sp_xml_removedocument @hdoc，否则句柄堆积会耗尽内存，尤其在存储过程中反复调用时
DECLARE @hdoc INT; EXEC sp_xml_preparedocument @hdoc OUTPUT, '<root><item id="101" qty="5"/></root>'; SELECT o.order_no, x.qty FROM OPENXML(@hdoc, '/root/item', 2) WITH (id INT '@id', qty INT '@qty') AS x JOIN orders o ON x.id = o.order_id; EXEC sp_xml_removedocument @hdoc;
PostgreSQL 中用 xpath() 提取 XML 并关联表（无 OPENXML）
PostgreSQL 没有 OPENXML，但 xpath() + UNNEST() 组合更灵活，也更易踩坑：返回的是 xml[] 数组，不显式转类型就会报错，而且路径写错不会提示，只会返回空数组。
关键点是：XML 命名空间、文本节点提取、以及如何避免多对一 JOIN 导致的行爆炸。
-
xpath('/item/@id', xml_col)返回xml[]，必须用::TEXT[]强转，再UNNEST()才能得到可 JOIN 的标量值 - 如果 XML 含命名空间（如
<e:item xmlns:e="http://ex.com">），xpath()必须传入命名空间映射，否则路径全失效：xpath('//e:item/@id', xml_col, ARRAY[ARRAY['e', 'http://ex.com']]) - 用
CROSS JOIN LATERAL替代老式逗号 JOIN，能确保每条 XML 只展开一次，避免因UNNEST()和主表产生意外乘积 -
xpath()性能弱于XMLTABLE（PG 10+），但XMLTABLE不支持变量路径，动态场景还是得靠xpath()
SELECT o.order_no, u.id::TEXT AS item_id
FROM orders o
CROSS JOIN LATERAL UNNEST(
xpath('/order/items/item/@id', o.xml_payload)
) AS u(id);
MySQL 8.0+ 用 ExtractValue() 或 JSON_TABLE 模拟 XML 关联
MySQL 对 XML 支持极弱，ExtractValue() 已被标记为 deprecated，且只能取单个值；真要联合查询，得先把 XML 转成 JSON 再用 JSON_TABLE —— 这是目前最可行的路，但转换过程容易丢数据。
注意：MySQL 的 XML 解析不处理 CDATA、注释、命名空间，任何复杂结构都会让 ExtractValue() 返回 NULL。
-
ExtractValue(xml_col, '//item/@id')最多返回前 100 个匹配项，且用空格拼接，无法区分单值/多值，不适合 JOIN 场景 - 稳妥做法是用应用层或存储过程先调
REPLACE()清洗 XML 成类 JSON 格式，再用JSON_TABLE解析，例如把<item id="1"><name>a</name></item>改成[{"id":"1","name":"a"}] -
JSON_TABLE的COLUMNS子句必须声明所有字段类型，id VARCHAR(20) PATH '$.id'比id JSON PATH '$.id'更安全，后者可能让后续 JOIN 类型隐式转换失败
为什么别在 WHERE 里用 XML 函数过滤大表
无论 SQL Server 的 OPENXML、PostgreSQL 的 xpath()，还是 MySQL 的 ExtractValue()，它们都无法利用索引——XML 字段本身不支持传统 B-tree 索引，函数结果更是计算列，优化器只能全表扫描。
线上查 10 万行 XML 数据，哪怕只取 @status='active'，响应时间也可能从毫秒级跳到秒级。
- 真正可行的方案是：提前物化关键字段。比如在 XML 插入时，用触发器或应用层同步把
@status写入一个新列xml_status VARCHAR(20)，然后在这个列上建索引 - SQL Server 可建 XML 索引，但只对
PRIMARY XML INDEX有效，且占用额外 2–3 倍磁盘空间，更新频繁的表慎用 - PostgreSQL 可对
xpath()结果建函数索引：CREATE INDEX idx_xml_status ON orders ((xpath('//item/@status', xml_payload)::TEXT[])[1]));，但要注意数组下标越界会报错，得加COALESCE容错
XML 和关系表硬 JOIN 的本质，是拿易读性换性能。只要数据量超过几千行，就得考虑字段拆解或预计算——这不是技巧问题，是存储模型冲突的必然结果。
