listagg默认返回varchar2且超4000字节报ora-01489，必须预先选择方案；需配合group by和within group使用，order by字段须在select或group by中出现；on overflow选项行为各异，cast为clob或xmlagg可突破长度限制，但insert时目标列类型必须匹配。
LISTAGG 默认只返回 VARCHAR2，超 4000 字节就报 ORA-01489，不是警告，是直接中断执行。 你不能靠“试试看”来规避——必须在写 SQL 前就决定用哪种方案，否则上线后查到一半崩掉，没人替你背锅。
LISTAGG 必须带 GROUP BY 和 WITHIN GROUP，否则直接报 ORA-00937
裸写 SELECT LISTAGG(name, ',') 是无效语法。Oracle 把它当聚合函数，没分组上下文就拒绝执行。
- 必须显式写
GROUP BY dept_id（或其它分组字段），且该字段要出现在SELECT列表里 -
WITHIN GROUP (ORDER BY emp_name)中的emp_name必须可排序：要么在SELECT中出现，要么在GROUP BY中出现，否则触发ORA-30496 - 哪怕不关心顺序，也得写
ORDER BY 1或ORDER BY dept_id；ORDER BY NULL虽语法通过，但 Oracle 不保证结果稳定性，别用 - 如果分组依据是表达式（比如
TRUNC(order_date)），那它必须原样出现在GROUP BY和SELECT中，不能写成TRUNC(order_date) AS dt然后在GROUP BY dt—— Oracle 不认别名
超长字符串：ON OVERFLOW 不是万能解药，选错等于丢数据
LISTAGG 在 12cR2+ 支持 ON OVERFLOW，但四个选项行为差异极大，生产环境慎选。
-
ON OVERFLOW ERROR：默认行为，报ORA-01489并终止查询 —— 最安全，适合强一致性场景 -
ON OVERFLOW TRUNCATE '…'：截断后加省略号，但要注意预留长度 —— 分隔符 + 省略号本身占字节，比如用', …'就占 3 字节，实际可用空间少于 4000 -
ON OVERFLOW TRUNCATE（无参数）：静默截断，不提示、不报错、不加标记 —— 数据被砍了你也发现不了，排查时极难定位 -
ON OVERFLOW NULL：整组结果变NULL—— 适合下游能容忍空值、且需明确感知溢出的流程 - 真正突破 4000 限制，得靠类型转换：
CAST(LISTAGG(...) AS CLOB)，否则即使加了ON OVERFLOW，插入目标字段仍是VARCHAR2，照样卡住
替代方案：XMLAGG 返回 CLOB，但语法和性能都得掂量
当确定拼接结果大概率超长，又不想冒险用 ON OVERFLOW TRUNCATE，XMLAGG 是更稳妥的选择，但它不是 LISTAGG 的无缝替换。
- 典型写法：
TRIM(',' FROM XMLCAST(XMLAGG(XMLELEMENT(E, emp_name || ',') ORDER BY emp_name) AS CLOB))—— 注意XMLELEMENT生成的是带标签的 XML，得用XMLCAST提取文本再TRIM掉末尾逗号 - 另一种写法：
XMLAGG(XMLPARSE(CONTENT emp_name || ',' WELLFORMED) ORDER BY emp_name).GETCLOBVAL()—— 更简洁，但WELLFORMED要求emp_name不能含非法 XML 字符（如、<code>&），否则报ORA-31061 - 性能比
LISTAGG低 20%~40%，尤其数据量大时明显；但胜在 CLOB 无硬上限，适合导出、日志、接口传参等对长度敏感的场景 - 如果只是临时查数据看一眼，
XMLAGG没问题；但若嵌在高频报表或物化视图里，得压测确认吞吐是否达标
最易被忽略的点：INSERT 场景下，目标列类型必须匹配。就算你写了 CAST(LISTAGG(...) AS CLOB)，如果目标表字段还是 VARCHAR2(4000)，插入时照样报错 —— 类型转换发生在 SELECT 阶段，但 INSERT 会做隐式转换校验，这步绕不过。
