Oracle 19c中LISTAGG默认返回VARCHAR2(4000)，超长必报ORA-01489；须显式使用ON OVERFLOW子句或CAST为CLOB，且GROUP BY与WITHIN GROUP顺序必须严格匹配。
LISTAGG 在 Oracle 19c 中默认仍返回 VARCHAR2，超 4000 字节必报 ORA-01489，不加处理直接用就是生产事故。
必须显式处理 ON OVERFLOW 才能避免硬报错
Oracle 12cR2 起支持 ON OVERFLOW，但 19c 里它不是“自动兜底”，而是需要你主动写出来——漏写就等于没开。默认行为仍是 ON OVERFLOW ERROR，即直接中断查询。
-
ON OVERFLOW TRUNCATE '…'：截断并补省略号，注意分隔符+省略号本身占字节（如',…'占 3 字节），要从 4000 里扣掉 -
ON OVERFLOW TRUNCATE（无参数）：静默截断，结果不可靠，调试时根本看不出丢数据 -
ON OVERFLOW NULL：整组变 NULL，适合强校验流程，但下游字段非空约束会立刻暴露 - 真正安全的兜底是
ON OVERFLOW ERROR+ 应用层捕获异常，而不是依赖截断
突破 4000 限制必须 CAST 为 CLOB
即使用了 ON OVERFLOW TRUNCATE，返回类型仍是 VARCHAR2；想存更长结果，目标列或表达式必须显式转成 CLOB。否则 INSERT 或赋值到 VARCHAR2 字段时，仍卡在 4000 截断上。
- 正确写法：
CAST(LISTAGG(col, ',') WITHIN GROUP (ORDER BY col) AS CLOB) - 错误写法：
LISTAGG(col, ',') WITHIN GROUP (ORDER BY col) ON OVERFLOW TRUNCATE→ 还是 VARCHAR2 - 注意：CLOB 虽无 4000 限制，但
XMLAGG方案性能明显更低，19c 下优先用 CAST + ON OVERFLOW 组合
GROUP BY 和 WITHIN GROUP 的顺序必须严格匹配
ORA-00937 或 ORA-30496 常不是溢出问题，而是语法错位导致 LISTAGG 根本没执行到溢出判断阶段。
-
WITHIN GROUP (ORDER BY ...)里的字段，必须出现在SELECT或GROUP BY中；不能只写ORDER BY 1就完事（语义模糊，19c 不推荐） - 若分组键是表达式（如
TRUNC(order_date)），GROUP BY和SELECT都得原样写出，不能简化为别名 - LEFT JOIN 后对主表
GROUP BY t.*是危险操作——Oracle 版本差异可能导致字段解析失败，应显式列出所有非聚合字段
DISTINCT 在 19c 可用，但不解决溢出
19c 确实支持 LISTAGG(DISTINCT col, ',')，但它只减少重复项数量，不改变单个值长度或拼接总长。去重后仍可能超限。
- 去重本身有性能开销，大数据量下建议前置子查询过滤，而非依赖 LISTAGG 内置 DISTINCT
- NULL 处理仍需手动包裹：
NVL(col, '(null)')，否则 NULL 被跳过，可能让实际拼接长度比预期短，掩盖溢出风险 - 字符集影响字节计算：UTF-8 下中文一个字占 3 字节，按字符数估算长度会严重误判
最易被忽略的是：溢出判断发生在整个聚合完成之后，不是逐行累加时检查。哪怕中间某条记录就超长，也要等全部拼完才报错——这意味着无法靠 LIMIT 或分页规避，只能靠预估长度或强制转 CLOB。
