listagg超4000字节必报ora-01489错误，因其默认返回varchar2类型且硬性限制4000字节；需显式使用on overflow选项或cast为clob，并确保目标列类型匹配。
LISTAGG超4000字节直接报ORA-01489，不是警告
Oracle默认返回VARCHAR2，硬性限制4000字节。哪怕拼接结果是3999字节+1个逗号，也会炸——ORA-01489: result of string concatenation is too long。这不是配置问题，是类型底层约束。
- 别指望
ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR能绕过，它只影响字符长度计算，不改变VARCHAR2上限 -
ON OVERFLOW TRUNCATE在12cR2引入，但19c里仍需显式声明，否则就是报错中断 - 如果目标表字段是
VARCHAR2(4000)，即使LISTAGG加了ON OVERFLOW，插入时仍会因类型不匹配失败
ON OVERFLOW选项选错等于丢数据
ON OVERFLOW有四个行为，选错一个就可能线上出事：
-
ON OVERFLOW ERROR：默认行为，安全但中断流程；适合ETL校验阶段 -
ON OVERFLOW TRUNCATE '…'：截断后补指定字符串，注意分隔符+省略号占额外字节（比如', …'占3字节） -
ON OVERFLOW TRUNCATE（无参数）：静默截断，无提示、无日志，极易漏检——生产环境禁用 -
ON OVERFLOW NULL：整组结果变NULL，适合强一致性要求场景，但下游必须能处理空值
突破4000限制必须CAST为CLOB
要真正支持长文本拼接，不能只靠ON OVERFLOW，得从类型层面解决：
- 查询中必须显式写
CAST(LISTAGG(...) AS CLOB)，否则即使源数据够长，Oracle仍按VARCHAR2路径执行 - 插入目标表时，对应字段必须定义为
CLOB，否则ORA-00932: inconsistent datatypes - 注意
CLOB字段在索引、排序、比较上的限制，比如ORDER BY字段不能是CLOB，需改用SUBSTR(clob_col, 1, 4000)等折中方式
GROUP BY字段含表达式时，WITHIN GROUP的ORDER BY必须严格一致
这个坑和溢出无关，但常一起触发：当GROUP BY用TRUNC(order_date)，而WITHIN GROUP (ORDER BY order_date)没同步改成TRUNC(order_date)，会先报ORA-30496（排序字段不在GROUP BY中），导致整个查询失败——你根本等不到溢出报错那一步。
- 检查点：所有出现在
SELECT或GROUP BY里的表达式，只要进LISTAGG的ORDER BY，就得原样复现 - 别用
ORDER BY 1偷懒，它在含表达式的场景下语义模糊，19c已不推荐
