LISTAGG 默认返回 VARCHAR2 类型，受 4000 字节硬限制，超限即报 ORA-01489；12cR2+ 可用 ON OVERFLOW 或 TO_CLOB 绕过，11g 则需 XMLAGG 或递归拼接。
LISTAGG 超长直接报 ORA-01489，不是写法错，是 VARCHAR2 类型硬限制——结果超 4000 字节就崩，没商量。
为什么 LISTAGG 默认会触发 ORA-01489？
根本原因是 LISTAGG 在未显式干预时返回 VARCHAR2，而 Oracle 的 VARCHAR2 最大长度就是 4000 字节（单字节字符集下）。哪怕你只拼 10 行、每行平均 500 字节，也可能轻松突破。这不是数据量大才出问题，而是只要中间结果 >4000 字节，执行瞬间就报错。
常见诱因包括：
- 分隔符过长（比如用
' | '比','多占 2 字节，1000 行就多 2000 字节） - 源字段含空格或不可见字符（
RTRIM/TRIM没做，白占空间） - 排序字段本身冗长（
ORDER BY long_description不仅慢，还让聚合过程更易超限）
12cR2+ 环境：用 ON OVERFLOW 或 TO_CLOB 强制绕过限制
Oracle 12.2 开始支持两个关键语法补丁，不用改逻辑就能保命：
-
ON OVERFLOW TRUNCATE '' WITHOUT COUNT：超长时静默截断，末尾不加提示；加WITH COUNT可在末尾显示截断行数，如... (32 more) -
LISTAGG(col, TO_CLOB(', ')) WITHIN GROUP (ORDER BY ...)：只要分隔符是CLOB类型，整个结果自动升为CLOB，彻底摆脱 4000 字节枷锁
注意：ON OVERFLOW 在 11g 和 12cR1 中完全不可用；TO_CLOB 方式要求所有拼接值本身不能预先超 4000 字节（否则在转 CLOB 前就已报 ORA-01489）。
必须兼容 11g 或超大数据集：回归 XMLAGG 或手写递归拼接
如果数据库卡在 11g R2，或拼接结果动辄几十万字节（比如日志合并、SQL 脚本生成），LISTAGG 就不该是首选：
- 用
XMLAGG(XMLELEMENT(e, col || ',')).EXTRACT('//text()').GETCLOBVAL()：返回原生CLOB，无长度焦虑，但性能略低于LISTAGG，且需清理末尾多余逗号 - 用递归
WITH+ROW_NUMBER()分批聚合：适合行数可控（status = 'ACTIVE' 的记录 - 禁用
WM_CONCAT：它早被 Oracle 移除，19c/21c 直接报ORA-00904: "WM_CONCAT": invalid identifier，11g 即使能用也无排序、无分隔符控制、超长静默截断，生产环境等于埋雷
PL/SQL 里拼字符串？别用 ||，用 DBMS_LOB.WRITEAPPEND
在存储过程中循环拼接，str := str || new_part 是典型陷阱：
- 每次
||都新建VARCHAR2对象，内存占用指数增长，极易触发ORA-06502 - 哪怕
str已声明为CLOB，||运算仍强制转VARCHAR2，再隐式转回引发ORA-22835
正确姿势是：
DBMS_LOB.CREATETEMPORARY(l_clob, TRUE); FOR r IN (SELECT col FROM t WHERE ...) LOOP DBMS_LOB.WRITEAPPEND(l_clob, LENGTH(r.col), r.col); IF NOT l_first THEN DBMS_LOB.WRITEAPPEND(l_clob, 1, ','); END IF; l_first := FALSE; END LOOP; -- 后续用完必须 DBMS_LOB.FREETEMPORARY(l_clob)，漏掉一次，下次可能因内存不足静默失败
最常被忽略的点：临时 CLOB 必须配对 FREETEMPORARY；ON OVERFLOW 写法在低版本无效；LISTAGG 的 ORDER BY 缺失必报 ORA-30497 —— 这些都不是“可能出错”，而是“必然出错”。
