xmltable解析xml报文需显式声明命名空间、注意xpath上下文路径、避免多节点返回错误；正确使用xmlnamespaces、相对路径、text()及索引语法可解决90%解析失败问题。
XMLTABLE 解析 XML 报文时，必须显式声明命名空间
很多 XML 报文（尤其是金融、政务接口返回）带 xmlns 声明，比如 <root xmlns="http://example.com/ns"></root>。如果忽略这个，XMLTABLE 会查不到任何节点，返回空结果——不是语法错，也不是报错，就是静默失败。
正确做法是在 XMLTABLE 的 XMLNAMESPACES 子句中绑定前缀：
SELECT *
FROM XMLTABLE(
XMLNAMESPACES('http://example.com/ns' AS "ns"),
'/ns:root/ns:item'
PASSING xmlparse(document '<root xmlns="http://example.com/ns"><item><id>1</id></item></root>')
COLUMNS id INT PATH 'ns:id'
);
- 没写
XMLNAMESPACES，/root/item路径完全匹配不上 - 前缀名（如
"ns"）要和 XPath 中一致，大小写敏感 - Oracle 和 PostgreSQL 都支持该语法，但 SQL Server 不支持
XMLTABLE，得用.nodes()+.value()
用 XPath 提取多层嵌套字段时，PATH 表达式不能省略父路径
XMLTABLE 的 COLUMNS ... PATH 是相对当前行节点的路径，不是整棵 XML 树的绝对路径。常见错误是写成 '/root/item/id'，实际应写成 'id' 或 './id' —— 因为当前上下文已经是 /root/item 节点。
例如解析订单中的多个商品：
SELECT order_id, sku, qty
FROM XMLTABLE(
'/order/items/item'
PASSING xml_data
COLUMNS
order_id STRING PATH '../../@id', -- 注意：向上跨两级取 order 的属性
sku STRING PATH 'product/sku',
qty INT PATH 'quantity'
);
-
../../@id是合法的，但过度跳转易出错；更稳的方式是分两层XMLTABLE嵌套 - 用
@attr提取属性，用text()提取文本内容（如PATH 'price/text()'），否则可能返回带空白的字符串 - PostgreSQL 对
text()支持稳定；Oracle 12c+ 也支持，但老版本需用.替代
XMLTABLE 性能差？先确认是不是在 SELECT 中反复解析同一 XML 字段
如果表里存的是 XML 字段（如 xml_content XML），又在 SELECT 里直接对它调用 XMLTABLE，数据库每次都会重新解析整段 XML —— 即使只取一个子字段。尤其当 XML 很大或结果集行数多时，CPU 和内存开销明显。
- 把
XMLTABLE拆成 LATERAL JOIN（PostgreSQL）或 CROSS JOIN XMLTABLE（Oracle），让优化器有机会缓存解析中间态 - 高频查询场景下，考虑提前用触发器或应用层把关键字段冗余到普通列，避免运行时解析
- SQL Server 用户注意：
.nodes()方法底层也是逐行解析，同样有性能瓶颈，且不支持并行化
遇到 “XQST0019” 或 “ORA-19279” 错误，大概率是 XPath 返回了多个节点
XMLTABLE 的每个 PATH 必须返回至多一个值。如果写成 PATH 'price'，而某条记录里 <price>10</price><price>20</price> 出现两次，Oracle 报 ORA-19279，PostgreSQL 报 XQST0019。
解决方式不是删数据，而是约束路径语义：
COLUMNS price1 DECIMAL PATH '(price)[1]', -- 取第一个 price2 DECIMAL PATH '(price)[2]', -- 取第二个 price_sum DECIMAL PATH 'sum(price)' -- 聚合计算（PostgreSQL 支持，Oracle 需额外处理）
-
(price)[1]比price[1]更可靠，括号明确优先级 - 用
count(price)判断重复数量，辅助排查数据质量 - 如果业务上本就不该有多值，应在入库时校验，而非在查询时兜底
XPath 路径看似简单，但命名空间、上下文、节点重复性这三点，几乎覆盖了 90% 的线上解析失败案例。真正难的不是写对一句 SQL，而是看懂对方给的 XML 到底长什么样——建议先用 XMLSERIALIZE 或 .value('(/root/@version)', 'varchar') 快速探查结构，再动 XMLTABLE。
