LISTAGG不支持DISTINCT参数，DB2/MySQL会报语法错误；应通过子查询预去重（如SELECT DISTINCT）再外层调用LISTAGG，并在WITHIN GROUP中明确ORDER BY以保证拼接顺序稳定。
LISTAGG本身不支持DISTINCT参数（尤其DB2/MySQL）
DB2和MySQL的LISTAGG函数语法不接受DISTINCT作为其直接参数。比如写LISTAGG(DISTINCT name, ',')，DB2会报SQL0104N错误，MySQL 8.0则直接提示语法错误——因为标准SQL中，DISTINCT是作用于查询结果集层级的关键字，不是标量函数的修饰符。Oracle是个例外，它扩展了语法支持，但其他主流数据库没跟。
子查询预去重是最直接、语义最清晰的替代方案
把去重逻辑提前到数据输入层，比在聚合函数里“硬塞”更符合SQL执行模型。实际操作就是两步走：
- 内层用
SELECT DISTINCT或GROUP BY产出唯一值组合（例如SELECT DISTINCT dept_id, emp_name FROM employees） - 外层对这个干净的结果集调用
LISTAGG，避免重复值进入聚合流程
这样既绕过语法限制，又避免了LISTAGG内部重复拼接再靠业务逻辑“擦屁股”的低效路径。
为什么不能靠外层GROUP BY或COUNT(DISTINCT)代替？
这些方法解决的是不同问题：
-
COUNT(DISTINCT x)只统计数量，不返回拼接字符串 -
GROUP BY x能分组，但若原始行含多列差异（如相同dept_id但不同hire_date），GROUP BY dept_id不会自动压缩emp_name列表，仍需配合LISTAGG - 如果直接
LISTAGG(emp_name, ',') GROUP BY dept_id却不预去重，重复员工名会被反复拼入结果，比如'Alice,Alice,Bob'
容易被忽略的细节：ORDER BY必须和去重逻辑对齐
子查询里用了DISTINCT，不代表顺序可控——DISTINCT不保证输出顺序。而LISTAGG ... WITHIN GROUP (ORDER BY ...)依赖输入行的有序性。所以正确写法是：
SELECT dept_id,
LISTAGG(emp_name, ', ') WITHIN GROUP (ORDER BY emp_name)
FROM (SELECT DISTINCT dept_id, emp_name FROM employees) AS deduped
GROUP BY dept_id;
这里ORDER BY emp_name作用于已去重后的结果集，才能确保拼接顺序稳定。漏掉这层排序，不同执行可能产出不同字符串，排查时很难复现。
