LISTAGG超长必报ORA-01489，须显式加ON OVERFLOW；12cR2+可用ON OVERFLOW TRUNCATE或RETURNING CLOB，低版本应改用XMLAGG+XMLELEMENT返回CLOB。
LISTAGG 超长直接报 ORA-01489，必须显式加 ON OVERFLOW
Oracle 12cR2+ 的 LISTAGG 默认不处理溢出，哪怕只超 1 字节也会崩出 ORA-01489: result of string concatenation is too long。这不是配置或驱动问题，是硬限制——不写 ON OVERFLOW 就等于没开溢出处理。
常见错误写法：LISTAGG(col, ',') WITHIN GROUP (ORDER BY col)，大数据量下必挂。
-
ON OVERFLOW ERROR：默认行为，等效于不写，整条 SQL 中断，报表类场景不可用 -
ON OVERFLOW TRUNCATE：必须显式写出，但末尾无标记，静默丢数据；调试时难定位 -
ON OVERFLOW TRUNCATE '…'：预留长度要算准分隔符和省略号本身字节数（如', …'占 3 字节） -
ON OVERFLOW NULL：整组结果变NULL，下游逻辑必须能判空并告警，否则断裂
注意：ON OVERFLOW TRUNCATE 仍受限于 VARCHAR2(4000)，不是“无限长”，只是不报错。
CAST(LISTAGG(...) AS CLOB) 是最简兼容解
如果目标字段或变量是 CLOB 类型，且你不想改逻辑结构，CAST 是最低侵入的补救方式。它不改变语义，只绕过 VARCHAR2 截断点。
示例：CAST(LISTAGG(name, ', ') WITHIN GROUP (ORDER BY id) ON OVERFLOW TRUNCATE '…' AS CLOB)
这个组合既满足长度突破，又保留截断可控性。但要注意：若上游已有 CLOB 字段参与拼接，LISTAGG 内部仍会尝试转成 VARCHAR2，所以 CAST 必须包住整个表达式，不能只包参数。
XMLAGG 才是真正突破长度限制的正解
当拼接结果可能远超 4000 字节、且要求完整不丢内容时，XMLAGG 是 Oracle 原生最稳的选择。它天然返回 CLOB，无隐式类型转换风险，也不依赖 ON OVERFLOW。
典型写法：RTRIM(XMLAGG(XMLELEMENT(e, col || ',')).EXTRACT('//text()').GETCLOBVAL(), ',')
- 必须用
XMLELEMENT包一层，否则XMLAGG可能报ORA-19011 -
EXTRACT('//text()').GETCLOBVAL()提取纯文本并转为CLOB -
RTRIM(..., ',')去掉末尾多余分隔符（也可用SUBSTR(..., 1, LENGTH(...) - 1)）
缺点是语法稍重，但胜在稳定可靠——尤其适合导出、日志聚合等对完整性要求高的场景。
PL/SQL 中拼接超长字符串别用 ||，要用 DBMS_LOB.WRITEAPPEND
在存储过程中循环拼接字符串，str := str || new_part 看似自然，实则危险：
-
||运算符永远返回VARCHAR2，超 4000 字节直接ORA-06502 - 若任一操作数是
CLOB，还会触发ORA-22835 - 每次拼接都新建对象，内存翻倍增长，极易 OOM
正确做法是用 DBMS_LOB 包：
先调 DBMS_LOB.CREATETEMPORARY(l_clob, TRUE) 创建临时 CLOB；循环中用 DBMS_LOB.WRITEAPPEND(l_clob, LENGTH(part), part) 追加；最后必须配对调 DBMS_LOB.FREETEMPORARY(l_clob)，漏掉一次就埋下内存泄漏隐患。
最容易被忽略的是：临时 CLOB 不 free，下次执行可能因内存不足而失败——这问题不报错，只缓慢恶化。
