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())。
