Oracle 19c起支持LISTAGG(DISTINCT...)，但需确认版本为19c/21c/23ai；分隔符必须显式指定，WITHIN GROUP排序可选但推荐使用；复杂场景（如含函数、NULL处理、超长截断）仍建议子查询去重。
Oracle 19c 中可以直接用 LISTAGG(DISTINCT ...) 去重合并，无需子查询或正则，但必须确认版本确实是 19c 或更高（12.2 不支持）。
确认是否真为 Oracle 19c 及以上
执行以下语句查实际版本：
SELECT * FROM v$version WHERE banner LIKE 'Oracle%';
只有输出中明确含 19c 或 21c、23ai 等才支持 DISTINCT 关键字。若显示 12.2.0.1.0 或 18c，则 LISTAGG(DISTINCT ...) 会报错 ORA-00936: missing expression。
- 19c 是首个正式支持
LISTAGG(DISTINCT ...)的长期支持版本 - 12cR2（12.2）仅增强溢出处理（
ON OVERFLOW），不支持去重 - 18c 属于“Release Update”，未引入该语法
直接使用 LISTAGG(DISTINCT ...) 的写法
语法简洁，但有两处易错点：
- 分隔符必须显式指定，不能省略（
LISTAGG(DISTINCT col, ',')✅；LISTAGG(DISTINCT col)❌ 报错） -
WITHIN GROUP (ORDER BY ...)在 19c 中可选，但若需控制去重后顺序，必须加上——否则结果顺序不确定 - 去重逻辑是「先去重、再排序、最后拼接」，不是按原始行序去重
示例：
SELECT deptno,
LISTAGG(DISTINCT ename, ', ') WITHIN GROUP (ORDER BY ename) AS names
FROM scott.emp
GROUP BY deptno;为什么有时仍要退回到子查询去重？
即使在 19c，以下情况也建议不用 DISTINCT 而改用子查询：
- 聚合列是表达式（如
UPPER(ename)），LISTAGG(DISTINCT UPPER(ename), ...)语法合法，但 Oracle 19c 实际执行时可能忽略DISTINCT（尤其涉及函数时） - 需要保留某类业务逻辑的“最后出现值”而非字典序去重（
DISTINCT总是无序去重） - 字段含
NULL且你希望把NULL当作独立值参与去重——DISTINCT会直接过滤掉NULL，而子查询可加NVL控制 - 拼接结果超长（>4000 字节），需配合
ON OVERFLOW TRUNCATE，但该子句与DISTINCT同时使用在部分 19c 补丁版本中存在兼容性问题
LISTAGG 去重的本质不是“字符串清洗”
很多人误以为 regexp_replace(...) 是在拼接后删重复子串，其实它只是碰巧能用——真正风险在于：
- 正则去重依赖逗号分隔且无嵌套、无转义，一旦数据含逗号（如地址字段）、空格或连续分隔符，就会错删或漏删
-
LISTAGG结果上限默认 4000 字节，正则替换会额外消耗内存，容易触发ORA-01489: result of string concatenation is too long - 子查询去重（
SELECT DISTINCT ...）才是语义清晰、可预测、可索引优化的方式，性能通常更好
所以哪怕在 19c，只要逻辑稍复杂，就别贪图 DISTINCT 的一行写法。真正的“去重合并”关键不在函数语法，而在你对源数据唯一性定义是否明确——这一步错了，后面全白搭。
