MySQL的GROUP_CONCAT默认最大长度为1024字符，需通过SET SESSION group_concat_max_len或修改my.cnf调大；支持SEPARATOR和DISTINCT；排序必须显式用ORDER BY，NULL默认被忽略。
MySQL 用 GROUP_CONCAT 拼接分组字符串，但默认长度被截断
很多人一用 GROUP_CONCAT 就发现结果被砍了一半，比如明明有 10 个用户名，只拼出前 3 个。这不是语法写错了，是 MySQL 默认限制了拼接结果最大长度为 1024 字符。
实际做法很简单，但必须显式调大：
- 临时生效（当前会话）：
SET SESSION group_concat_max_len = 10000; - 永久生效（需改配置文件）：在
my.cnf的[mysqld]下加一行group_concat_max_len = 10000 -
GROUP_CONCAT默认用逗号分隔，想换分隔符就加SEPARATOR ' | '，比如：GROUP_CONCAT(name SEPARATOR ' | ') - 它不自动去重，要排重得套
DISTINCT：GROUP_CONCAT(DISTINCT name)
Oracle 和 PostgreSQL 用 LISTAGG，但 Oracle 11g+ 才支持，且超长会报错
LISTAGG 在 Oracle 和 PostgreSQL 都有，但行为差异不小。Oracle 12c 开始支持 ON OVERFLOW TRUNCATE，而 11g 及之前版本一旦拼接结果超长，直接报错 ORA-01489: result of string concatenation is too long，没法兜底。
常见写法和坑点：
- Oracle 基础用法：
LISTAGG(name, ', ') WITHIN GROUP (ORDER BY id)—— 注意WITHIN GROUP是必需的，漏了会语法错误 - Oracle 12c+ 安全写法：
LISTAGG(name, ', ') WITHIN GROUP (ORDER BY id) ON OVERFLOW TRUNCATE '...' - PostgreSQL 的
LISTAGG其实是扩展函数（如string_agg），原生不叫LISTAGG；如果装了orafce扩展才支持同名函数，否则得用string_agg(name, ', ' ORDER BY id)
跨数据库兼容写法不存在，别硬套一个函数名到处用
看到别人代码里写 LISTAGG 就抄到 MySQL 里？马上报错 FUNCTION xxx.LISTAGG does not exist。反过来，把 GROUP_CONCAT 往 Oracle 里搬，也会提示无效函数名。
不同数据库对“分组拼接”这件事，底层实现逻辑和容错策略完全不同：
- MySQL 的
GROUP_CONCAT是聚合函数，但允许空值参与、默认忽略NULL，且结果类型是TEXT（受max_allowed_packet影响） - Oracle 的
LISTAGG是严格窗口/聚合函数，NULL值会被跳过，且 11g 不支持溢出处理，容易在线上突然失败 - PostgreSQL 推荐用
string_agg，它天然支持ORDER BY子句，也不容易截断，但没内置截断选项，超长只能靠应用层截
排序和空值处理不是可选项，而是必填项
很多人只写 GROUP_CONCAT(name) 或 LISTAGG(name, ', ')，结果每次查出来顺序都不一样。这不是 bug，是设计如此 —— 这些函数本身不保证顺序，除非你明确声明。
真实项目里，顺序错乱会导致比数据少更难排查的问题（比如导出报表时人名顺序随机）：
- MySQL 必须加
ORDER BY子句：GROUP_CONCAT(name ORDER BY created_at DESC) - Oracle / PostgreSQL 的
LISTAGG或string_agg的排序必须写在函数内部：LISTAGG(name, ', ') WITHIN GROUP (ORDER BY score DESC) -
NULL值默认被跳过，但如果你希望显示为'(unknown)'，就得提前用COALESCE(name, '(unknown)')处理，不能指望拼接函数帮你转
