ora-01489错误源于listagg结果超varchar2 4000字节限制，必须显式声明on overflow truncate（非默认行为），否则仍报错；中文等多字节字符更易触发，可改用xmlagg转clob确保完整。
Oracle 19c 中 LISTAGG 超长必报 ORA-01489，除非显式写 ON OVERFLOW TRUNCATE —— 不写就等同于没启用，不是默认行为。
LISTAGG ON OVERFLOW TRUNCATE 必须显式声明
很多人以为 19c 自动支持截断，结果一执行还是 ORA-01489。根本原因是：ON OVERFLOW 是可选子句，且 ON OVERFLOW ERROR（抛错）才是默认策略，ON OVERFLOW TRUNCATE 必须完整写出才生效。
-
LISTAGG(name, ',') WITHIN GROUP (ORDER BY id)→ 仍会报错 -
LISTAGG(name, ',') WITHIN GROUP (ORDER BY id) ON OVERFLOW TRUNCATE→ 正确，截断不报错 -
ON OVERFLOW TRUNCATE '' WITH COUNT可追加后缀，如生成Alice,Bob,... (5 more) - 注意：
TRUNCATE后总长仍受 VARCHAR2(4000) 限制，不是“无限长”，只是不崩
中文/UTF-8 场景下字节超限比想象中快
AL32UTF8 字符集里一个汉字占 3 字节，拼接 1400 个汉字就可能突破 4000 字节——别只数字符数，得按字节算。用 LENGTHB() 验证实际字节长度：
SELECT LENGTHB(LISTAGG(name, ',') WITHIN GROUP (ORDER BY id)) FROM employees;
- 若接近或超过 4000，即使字符数看起来不多，也必须加
ON OVERFLOW TRUNCATE - 不要用
SUBSTR(..., 1, 3999)套在 LISTAGG 外层，它不解决根本问题，还可能在分隔符中间截断 - 客户端字符集设置（如 NLS_LANG）不一致时，
LENGTHB和实际存储字节可能有偏差，优先以数据库服务端为准
需要完整保留内容？改用 XMLAGG + CLOB
当业务要求“一个字都不能丢”（比如审计日志、配置项合并），ON OVERFLOW TRUNCATE 就不合适了，必须升到 CLOB 层级：
SELECT RTRIM(
XMLAGG(XMLELEMENT(e, name || ', ').EXTRACT('//text()')).GETCLOBVAL(),
', '
) AS names
FROM employees;
-
XMLELEMENT会把&、等转义成 <code>&、，原始数据含 HTML 符号时需额外 <code>REPLACE - 性能比原生
LISTAGG低 20%–40%，大数据量分组前建议先跑执行计划（EXPLAIN PLAN） - Oracle 11gR2 起就支持 XMLAGG，兼容性比 LISTAGG 更广，但语法更冗长
空值（NULL）和排序字段容易连带出错
这两个问题常和溢出一起爆发，导致你以为是长度问题，其实是逻辑错误：
-
LISTAGG默认跳过 NULL，但如果拼接字段本身是 NULL 且未处理，整个聚合结果可能为 NULL（尤其在子查询嵌套中）→ 用NVL(name, '(unknown)')显式转换 -
ORDER BY必须写在WITHIN GROUP里，写在外面（如GROUP BY dept ORDER BY name）对拼接顺序完全无效，还可能引发 ORA-00979 - 排序字段必须出现在
GROUP BY列表中，否则报错；若要按非分组字段排序（如按创建时间排姓名），得先用子查询预排序
真正难的不是写对语法，而是意识到：ORA-01489 报错时，你面对的往往不是单一长度问题，而是字符集、空值、排序、版本特性四者叠加的隐性陷阱。每次遇到，先查 v$version，再看 LENGTHB，最后检查 WITHIN GROUP 里的每一处括号和逗号 —— 少一个都白搭。
