优先用 LISTAGG(... ON OVERFLOW TRUNCATE) 截断超长字符串，或 CAST(LISTAGG(...) AS CLOB) 绕过4000字节限制；排序必须写在 WITHIN GROUP(ORDER BY ...) 内；条件过滤用 CASE WHEN 而非外部 WHERE。
LISTAGG 会报 ORA-01489 错误怎么办
字符串超长是 listagg 最常见的翻车点：默认最大长度 4000 字节（varchar2 限制），一旦拼接结果超限，直接抛 ora-01489: result of string concatenation is too long。这不是数据问题，是类型天花板卡死的。
- 优先用
LISTAGG(... ON OVERFLOW TRUNCATE)显式声明截断策略，例如ON OVERFLOW TRUNCATE '...' WITH COUNT，避免语句直接失败 - 若必须保全内容，改用
CLOB类型输出：把聚合字段转成TO_CLOB(column_name)再拼接，但注意LISTAGG本身不原生返回 CLOB，需配合CAST或子查询绕过，例如CAST(LISTAGG(...) WITHIN GROUP (...) AS CLOB) - Oracle 12c 及以后支持
ON OVERFLOW ERROR（默认）或ON OVERFLOW TRUNCATE，别用老版本语法省略该子句
LISTAGG 的 ORDER BY 必须写在 WITHIN GROUP 里
很多人把排序写成外部 ORDER BY，结果发现拼接顺序乱套——LISTAGG 的排序逻辑只认 WITHIN GROUP (ORDER BY ...) 里的声明，外面的 ORDER BY 只影响最终结果集行序，对拼接内部毫无作用。
- 正确写法：
LISTAGG(name, ',') WITHIN GROUP (ORDER BY seq_no) - 错误写法：
LISTAGG(name, ',') WITHIN GROUP () ORDER BY seq_no（语法报错）或LISTAGG(name, ',') WITHIN GROUP () ORDER BY name（排序无效） - 如果排序字段含 NULL，记得加
NULLS FIRST或NULLS LAST，否则 Oracle 默认把 NULL 当最小值处理，可能排最前
需要条件过滤再拼接？别在 WHERE 里硬砍
比如“只拼接 status = 'A' 的 name”，如果直接在主查询 WHERE status = 'A'，会先过滤行再聚合，看似合理，但一旦分组键（如 group_id）下没有满足条件的记录，整行就消失了——而你可能希望拼出空字符串而非丢行。
- 用
CASE WHEN在聚合内部过滤：LISTAGG(CASE WHEN status = 'A' THEN name END, ',') WITHIN GROUP (ORDER BY name)，这样没匹配的返回 NULL，LISTAGG会跳过 NULL 值，结果为空字符串 - 若想保留分组结构且显示 “(无)” 这类占位符，得在外层用
NVL或COALESCE包一层：COALESCE(LISTAGG(...), '(无)') - PL/SQL 中动态拼接更灵活，但别为了简单逻辑就上存储过程——纯 SQL 能搞定的，别无谓引入上下文切换开销
PL/SQL 里手动拼接不如 LISTAGG 稳定
有人习惯写游标循环 + || 拼字符串，觉得可控。实际在大数据量下，这种做法容易触发 PGA 内存溢出（尤其字符串反复 realloc），而且无法利用并行执行计划。
-
LISTAGG是内置聚合函数，Oracle 对其做了大量优化，包括内存预分配和流式处理 - 若真要用 PL/SQL（比如要插入特殊分隔逻辑、调用函数加工每个值），务必用
VARCHAR2(32767)或CLOB变量，并在循环内用DBMS_LOB.WRITEAPPEND（对 CLOB）或累积时检查长度，避免隐式转换失败 - 特别注意：PL/SQL 中
||遇到任一操作数为 NULL，整个结果为 NULL——这和 SQL 的拼接行为一致，但容易被忽略导致结果意外为空
真正麻烦的不是语法怎么写，而是搞清你要拼的是“业务语义上的字符串”还是“可索引/可搜索的结构化值”。前者用 LISTAGG 加截断兜底，后者可能该用 JSON_OBJECTAGG 或拆表关联。
