ora-01489 错误源于 listagg 默认返回 varchar2(4000) 且不自动截断，须显式添加 on overflow truncate；常见误因是漏写或错放 within group (order by)，实际可能触发 ora-30496 而被误判。
ORA-01489 错误不是配置问题，而是 LISTAGG 在 SQL 层强制返回 VARCHAR2(4000) 的结果类型所致。Oracle 19c 确实支持截断，但必须显式写出 ON OVERFLOW TRUNCATE，否则仍报错。
LISTAGG 必须带 WITHIN GROUP (ORDER BY) 才能执行
漏写或错放 ORDER BY 是最常见误报 ORA-01489 的诱因之一——实际触发的是 ORA-30496，但用户常误判为溢出。错误写法如：SELECT LISTAGG(name, ',') FROM t ORDER BY name；正确写法必须把排序放进聚合子句内：
-
LISTAGG(name, ',') WITHIN GROUP (ORDER BY name)—— 分隔符必须用单引号包裹 - 排序字段最好来自
GROUP BY列，或语义上能被分组唯一确定，否则结果不稳定 - 若只需任意顺序，可用
WITHIN GROUP (ORDER BY NULL)（Oracle 允许），但部分版本会警告
ON OVERFLOW TRUNCATE 必须显式声明才生效
即使 Oracle 版本 ≥12.2（含 19c），不写 ON OVERFLOW 就等同于无该能力，仍会抛 ORA-01489。默认行为不是“自动截断”，而是“报错”。关键点：
- 完整语法必须是：
LISTAGG(col, ',') WITHIN GROUP (ORDER BY col) ON OVERFLOW TRUNCATE - 可选加后缀：
ON OVERFLOW TRUNCATE '…' WITH COUNT，会在末尾补类似(5 more)的提示 -
TRUNCATE后总长仍受 VARCHAR2(4000) 限制，不是无限长；它只是把超长部分砍掉，不抛异常 - 不要嵌套
SUBSTR(LISTAGG(...), 1, 3999)：多一层计算、可能在字节边界截断导致乱码，且无法规避 ORA-01489
需要完整保留内容？改用 XMLAGG + CLOB
当业务要求“一个字都不能丢”（如审计日志、全量标签合并），ON OVERFLOW TRUNCATE 不适用，必须升格到 CLOB。核心组合是：
SELECT RTRIM(
XMLAGG(XMLELEMENT(e, col || ', ').EXTRACT('//text()').GETCLOBVAL(), ', ')
FROM t;
-
XMLELEMENT会自动转义&、等字符；若原始数据含 HTML 符号，需额外 <code>REPLACE还原 - 性能比原生
LISTAGG低 20%–40%，大数据量分组下务必看执行计划，必要时加索引或物化中间结果 - 注意字符集陷阱：UTF-8 下一个汉字占 3 字节，1000 个汉字就接近 3000 字节，离 4000 很近；别只数字符个数，要算字节
NULL、重复、空分组这些细节容易一起引爆
溢出问题常和其它 LISTAGG 行为叠加，让调试更难：
- NULL 值不会跳过，拼接后变成
a,,b；应提前WHERE col IS NOT NULL或用NVL(col, '') - 重复值照常拼入；去重要在外层子查询做：
SELECT LISTAGG(name, ',') WITHIN GROUP (ORDER BY name) FROM (SELECT DISTINCT name FROM t) - 空分组（如 LEFT JOIN 右表无匹配）返回
NULL，不是空字符串；后续用CONCAT或||会整条变 NULL，建议统一包一层COALESCE(LISTAGG(...), '')
真正麻烦的从来不是“怎么写”，而是“为什么写了还不行”——比如确认了 19c 版本却仍报错，大概率是漏了 ON OVERFLOW 子句，或字符集下字节算错。先查 SELECT banner FROM v$version，再盯死语法完整性，比反复换写法更省时间。
