GROUP_CONCAT被静默截断是因为group_concat_max_len默认仅1024字节，超长部分直接丢弃且不报错；需用SET SESSION或修改my.cnf调大该值，并注意其单位为字节、受UTF-8多字节字符和max_allowed_packet限制。

GROUP_CONCAT被静默截断是因为group_concat_max_len太小

不是SQL写错了，也不是客户端限制，而是MySQL服务端默认只允许拼出group_concat_max_len字节——值为1024，超了就丢，不报错、不警告。你看到的“少了一半数据”，大概率就是它在作怪。

关键点：group_concat_max_len单位是**字节**，不是字符。UTF-8下中文、emoji一个占3–4字节，1024字节可能连300个汉字都装不下；分隔符（如','）也会计入长度。

• 查当前限制：SELECT @@session.group_concat_max_len;
• 看实际拼了多少字节：SELECT LENGTH(GROUP_CONCAT(name)) FROM users GROUP BY dept;（注意用LENGTH，不是CHAR_LENGTH）
• 对比两者，差值明显就确认是截断问题

临时调大group_concat_max_len要带SESSION或GLOBAL关键字

只写SET group_concat_max_len = 10000是无效的——MySQL会静默忽略，不报错也不生效。必须明确作用域。

• 仅当前连接生效（推荐先试）：SET SESSION group_concat_max_len = 1000000;
• 对所有新连接生效（需SUPER权限）：SET GLOBAL group_concat_max_len = 1000000;
• 云数据库（如阿里云RDS）通常禁用SET GLOBAL，得去控制台改参数模板，且修改后需重启实例
• 用连接池（如HikariCP）时，必须在初始化SQL里加上SET SESSION，否则每次取连接都是默认1024

永久生效必须改my.cnf且重启MySQL

开发调试可以SET SESSION，但生产环境不改配置文件，服务一重启就回滚到1024，问题重现。

• 在my.cnf的[mysqld]段下加一行：group_concat_max_len = 1000000
• 改完必须重启MySQL服务，systemctl restart mysqld或对应命令
• 别漏掉max_allowed_packet这个硬门槛：如果拼接结果超过它，会直接报错Packet for query is too large；查当前值：SELECT @@max_allowed_packet;，建议设为至少和group_concat_max_len同量级

别用SUBSTRING绕过根本问题

SUBSTRING(GROUP_CONCAT(...), 1, 50)看起来能“控制长度”，但它是在拼完之后切——如果原始拼接已被group_concat_max_len截断，那切的只是那个残缺字符串。

• ❌ 错误做法：GROUP_CONCAT(SUBSTRING(name, 1, 10)) —— 这是对每个name先截再拼，不是控最终长度
• ✅ 正确顺序永远是：先确保group_concat_max_len够大，再考虑是否需要SUBSTRING做业务层裁剪
• 真正该换方案的时候：拼接内容含JSON、需要去NULL、条件过滤（如只拼status=1）、或长度动辄几万字节——这时候JSON_ARRAYAGG更稳，无长度硬限制，类型安全

最易被忽略的是字符集与字节的换算关系：同一个group_concat_max_len值，在utf8mb4和latin1下能拼的字符数差3–4倍。上线前务必用真实数据+真实字符集测一下LENGTH(GROUP_CONCAT())。