xmlagg更稳健，天然返回clob无4000字节硬限制，理论可达4gb；而listagg返回varchar2，超限必报ora-01489，且to_clob(listagg())无效，因溢出发生在转换前。
XMLAGG 更稳健，但代价是类型、性能和写法复杂度。LISTAGG 在超 4000 字节时必然抛出 ORA-01489，而 XMLAGG 天然返回 CLOB，无硬性长度上限（理论可达 4GB），只要内存和临时表空间够，就能拼到底。
LISTAGG 超长必报 ORA-01489 的根本原因
它返回的是 VARCHAR2，在 AL32UTF8 字符集下实际有效长度常低于 4000 字节（一个中文占 3 字节，4000 ÷ 3 ≈ 1333 个汉字就溢出）。哪怕你写 TO_CLOB(LISTAGG(...))，函数内部仍先按 VARCHAR2 拼接，错误发生在转换前，根本走不到 TO_CLOB 那一步。
-
ON OVERFLOW TRUNCATE只在 12.2+ 支持，且截断后丢失数据，不适用于审计、导出等需完整结果的场景 -
ON OVERFLOW ERROR是默认行为，应用层必须捕获并降级，增加异常处理负担 - 即使分组数据量不大，字段含多字节字符（如 emoji、生僻字）也容易意外触发
XMLAGG 返回 CLOB 的典型写法与要点
最常用且兼容性好的组合是 XMLAGG + XMLELEMENT + EXTRACT('//text()') + RTRIM：
SELECT RTRIM(
XMLAGG(XMLELEMENT(e, employee_name || ',') ORDER BY employee_id)
.EXTRACT('//text()').GETCLOBVAL(),
','
) AS names
FROM employees
GROUP BY department_id;
- 必须写
ORDER BY，否则拼接顺序不确定——XMLAGG本身不保证顺序 -
EXTRACT('//text()')比直接用GETCLOBVAL()更干净，避免 XML 标签残留 - 结尾用
RTRIM(..., ',')去掉末尾多余分隔符；若用XMLPARSE(CONTENT ... WELLFORMED)，需确保字段内容不含非法 XML 字符（如、<code>&），否则报错
XMLAGG 的隐性成本不能忽略
它不是 LISTAGG 的“无缝替代”，实际落地时要主动应对几个现实约束：
- 返回值是
CLOB，不能直接参与=、IN、LIKE等字符串运算，后续若需WHERE names LIKE '%xxx%'，得显式转成TO_CHAR(names)，但 CLOB > 4000 字节时TO_CHAR会截断 - 执行计划中通常显示为
SORT AGGREGATE+XMLSEQUENCE，比 LISTAGG 多一到两层函数调用，大数据量下 CPU 和 temp space 消耗明显更高 - Oracle 11gR2+ 全支持，但某些老应用框架对
CLOB字段映射不友好，可能需要改 JDBC fetch size 或 ORM 配置
真正棘手的不是“选哪个函数”，而是确认下游是否真能消费 CLOB —— 很多报表工具或中间件只认 VARCHAR2，这时候宁可拆成多次 LISTAGG 分页拼接，也别让 XMLAGG 返回的 CLOB 卡在链路中间。
