LISTAGG超长必报ORA-01489，须显式加ON OVERFLOW子句；CAST转CLOB可绕过4000字节限制，但溢出仍需ON OVERFLOW配合；XMLAGG才是突破长度限制的正解。
LISTAGG 超长直接报 ORA-01489，不是配置问题，是 Oracle 硬限制 —— 必须显式处理溢出或换方案。
LISTAGG 必须带 ON OVERFLOW 才能避免 ORA-01489
Oracle 12cR2+ 支持 ON OVERFLOW 子句，但不写就等于没开；漏掉它，哪怕只超 1 字节也会崩。旧写法 LISTAGG(col, ',') WITHIN GROUP (ORDER BY col) 在大数据量下必然失败。
-
ON OVERFLOW ERROR：默认行为，不写也等效，但会中断整个查询 —— 不适合报表类场景 -
ON OVERFLOW TRUNCATE：必须显式写出，截断后不报错，但末尾不加标记 —— 容易静默丢数据，调试时难定位 -
ON OVERFLOW TRUNCATE '…'：预留长度要算准分隔符和省略号本身字节数（如', …'占 3 字节） -
ON OVERFLOW NULL：整组结果变NULL，下游需能判空并告警，否则逻辑断裂
注意：ON OVERFLOW TRUNCATE 仍受限于 VARCHAR2(4000)，不是“无限长”，只是不报错。
CAST(LISTAGG(...) AS CLOB) 是最简兼容解
如果目标字段或变量是 CLOB 类型，且你不想改逻辑结构，CAST 是最低侵入的补救方式。它不改变语义，只绕过 VARCHAR2 截断点。
- 必须对整个
LISTAGG表达式CAST，不能只 cast 分隔符或字段 - 写法示例：
CAST(LISTAGG(name, ', ') WITHIN GROUP (ORDER BY name) ON OVERFLOW TRUNCATE AS CLOB) - 若未加
ON OVERFLOW，CAST无效 —— 溢出发生在聚合阶段，类型转换晚了一步 - 插入到
CLOB列时，该写法可保 32767 字节内安全；超了仍需换方案
XMLAGG + EXTRACT 是真正突破 4000 字节的正解
当业务要求“一个字都不能丢”（比如日志归集、SQL 脚本生成），XMLAGG 是唯一稳妥路径。它原生返回 CLOB，不受 VARCHAR2 字节限制约束。
- 基础写法：
RTRIM(XMLAGG(XMLELEMENT(e, col || ', ') ORDER BY col).EXTRACT('//text()').GETCLOBVAL(), ', ') -
XMLELEMENT会自动转义&、、<code>>—— 若原始数据含 HTML/SQL 片段，得套REPLACE(REPLACE(..., '&', '&'), '<', ' - 性能比
LISTAGG低 20%–40%，大数据量分组前建议跑执行计划对比 - 别用
WM_CONCAT：11g 里它无排序、无分隔符控制、超长静默截断；19c/21c 直接报ORA-00904: "WM_CONCAT": invalid identifier
字符集陷阱常被忽略：UTF-8 下 4000 字节 ≠ 4000 字符
AL32UTF8 字符集下，一个中文占 3 字节，一个 emoji 占 4 字节。用 LENGTH(name) 看长度毫无意义，得看字节长。
- 查单值字节数：
DUMP(name, 1016)，输出形如Typ=1 Len=6: 0xe4,0xbd,0xa0,0xe5,0xa5,0xbd，Len=6 就是 6 字节 - 预估分组总长：
SUM(LENGTHB(col)) + (COUNT(*) - 1) * LENGTHB(',')，超 4000 就该切到XMLAGG - 别信“我只拼了 1500 个汉字所以肯定够” —— 1500 × 3 = 4500 字节，已经溢出
真正麻烦的不是语法怎么写，而是你得在写 SQL 前就想好：这组数据最大可能多长？字符集怎么算？下游能不能接受截断？—— 这些判断错了，后面全白调。
