Oracle从9i开始引入XMLType类型，到10g、11g逐步完善了SQL/XML标准函数的支持，其中XQuery和XMLTable是处理半结构化数据的两大利器。很多业务系统会把接口报文、配置文件、单据明细以XML形式存进CLOB或XMLType字段，如果用SUBSTR加INSTR这种字符串切割方式解析，代码既难维护又容易出错。掌握XQuery查询语法和XMLTable的行拆解能力，可以让XML数据的处理像操作普通表一样简单。
XQuery基础与XMLQuery函数
XQuery是W3C制定的XML查询语言，Oracle在其实现中以FLWOR表达式为核心，即for、let、where、order by、return五个关键字组合的查询结构。通过SQL函数XMLQuery，可以把一段XQuery嵌入到普通SQL语句中，返回值是XMLType类型。
先准备一张测试表并插入样例数据：
CREATE TABLE t_order_doc (
id NUMBER PRIMARY KEY,
doc XMLType
);
INSERT INTO t_order_doc VALUES (1, XMLType(
'<order>
<customer>张三</customer>
<items>
<item>
<name>机械键盘</name>
<qty>2</qty>
<price>399</price>
</item>
<item>
<name>显示器</name>
<qty>1</qty>
<price>1299</price>
</item>
</items>
</order>'));使用XMLQuery配合XQuery路径表达式，可以提取任意节点。下面的语句查询订单客户名：
SELECT XMLQuery('/order/customer/text()'
PASSING t.doc RETURNING CONTENT) AS customer
FROM t_order_doc t
WHERE t.id = 1;如果要执行更复杂的逻辑，可以写FLWOR表达式。例如筛选价格高于500的商品并重新组织输出结构：
SELECT XMLQuery(
'for $i in /order/items/item
where $i/price > 500
return <expensive>{$i/name/text()}</expensive>'
PASSING t.doc RETURNING CONTENT) AS result
FROM t_order_doc t;需要注意Oracle的XQuery实现遵循标准语法，变量必须以$开头，for子句绑定节点序列，where子句做过滤，return子句构造结果。XMLQuery返回的是XML片段，如果只想要标量文本，用.text()或改用XMLTable更方便。
XMLTable把XML拆成关系表
XMLTable是XML shredding的核心工具，它接收一个XQuery表达式，把返回的节点序列展开为结果集的行，再通过COLUMNS子句把每个节点的子元素映射为普通SQL列。这一步完成后，XML数据就能和普通表一样参与JOIN、聚合、过滤，甚至直接建视图对外提供关系型接口。
基本用法示例：
SELECT x.name, x.qty, x.price
FROM t_order_doc t,
XMLTable('/order/items/item'
PASSING t.doc
COLUMNS name VARCHAR2(50) PATH 'name',
qty NUMBER PATH 'qty',
price NUMBER PATH 'price') x;这条语句会把两个item节点拆成两行记录输出。COLUMNS子句中的PATH是相对于XMLTable第一个参数所选节点的相对路径，省略时默认取同名子节点。列类型可以是VARCHAR2、NUMBER、DATE等常规类型，也可以定义为XMLType以保留原始片段，供后续继续拆解。
对于多层嵌套的结构，例如一个客户对应多个订单、每个订单又有多个明细，可以用多层XMLTable嵌套查询，外层拆客户和订单节点，内层用PASSING把上一步得到的XMLType列继续传入拆解：
SELECT c.cust, o.order_id, i.item_name
FROM t_xml_data t,
XMLTable('/customers/customer' PASSING t.doc
COLUMNS cust VARCHAR2(30) PATH '@name',
order_node XMLType PATH 'orders/order') c,
XMLTable('/order' PASSING c.order_node
COLUMNS order_id NUMBER PATH '@id',
item_node XMLType PATH 'items/item') o,
XMLTable('/item' PASSING o.item_node
COLUMNS item_name VARCHAR2(50) PATH 'name') i;注意示例中@name、@id这种写法用于提取XML属性而不是子节点，这是XPath的通用规则，在XMLTable的PATH中同样适用。嵌套拆解时每一层输出一个XMLType中间列，层层传递，逻辑非常清晰，比写一个巨大的XPath要容易维护得多。
命名空间处理与常见报错排查
真实接口报文往往带有默认命名空间或前缀，例如SOAP报文的xmlns声明。如果XQuery路径不声明命名空间，会匹配不到任何节点，查询返回空结果集，这是新手最容易踩的坑。解决办法是在XQuery prolog中使用declare namespace声明前缀，或者用declare default element namespace处理默认命名空间：
SELECT x.val
FROM t_soap_log t,
XMLTable(
'declare default element namespace "http://schemas.xmlsoap.org/soap/envelope/";
/Envelope/Body'
PASSING t.doc
COLUMNS val VARCHAR2(200) PATH 'text()') x;另一个常见坑是继续使用EXTRACT、EXTRACTVALUE这些旧函数。EXTRACTVALUE只能返回单一节点的标量值，遇到多节点会直接报ORA-19025错误，而且Oracle官方已将其标记为废弃。新项目建议统一改用XMLTable和XMLQuery，旧函数在部分场景下无法利用结构化索引优化，性能差距可能达到数倍。
报文编码也要留意。如果XML声明中写的是GBK而数据库字符集是AL32UTF8，插入XMLType时可能报字符集转换相关错误，此时应把数据先存入BLOB再通过指定编码参数创建XMLType，或者在应用层统一转换为UTF-8后再落库。此外，路径写错时通常不报错而是返回NULL，排查时应先用XMLSerialize把文档整体输出确认结构，再逐步缩小路径范围。
性能优化建议
当XML表数据量较大时，全表扫描加运行时解析的开销很高，需要从存储和索引两方面优化。首先确保存储方式合理：结构化存储比CLOB存储有更好的查询性能，11g之后XMLType默认采用结构化存储，老表可以考虑重建迁移。其次，对频繁查询的路径可以创建XMLIndex索引：
CREATE INDEX idx_order_items ON t_order_doc (doc)
INDEXTYPE IS XDB.XMLIndex
PARAMETERS ('PATH TABLE order_path_tab');建索引后，谓词条件如XMLExists('/order/customer[text()="张三"]', doc)会被改写为对路径表的查询，避免逐行解析XML文档，这对大文档表的过滤查询提升尤为明显。
编写查询时还有两个习惯值得坚持：一是尽量把过滤条件放进XQuery的where子句或XMLTable的PATH里，让数据库在解析阶段就做剪枝，而不是把所有行拆出来后再用SQL过滤；二是判断存在性时用XMLExists代替取值再判空，语义更清晰且优化器处理效率更高。路径表属于普通堆表，统计信息不要遗漏，否则可能因执行计划偏差导致查询突然变慢。
总结来说，XMLQuery负责构造和提取XML片段，XMLTable负责把XML拆解成行，两者搭配XQuery的FLWOR表达式，可以覆盖绝大多数半结构化数据的查询需求。再结合结构化存储和XMLIndex索引，Oracle处理XML的性能完全可以满足业务系统的要求。
Oracle XQueryXMLTableXML数据查询修改时间：2026-09-02 12:14:56