GROUP_CONCAT静默丢数据是因为group_concat_max_len默认仅1024字节，超长部分直接截断且不报错；其单位为字节（非字符），UTF-8中文、emoji占3–4字节，分隔符也计入长度，需通过SET SESSION或修改my.cnf调大该值，并同步调整max_allowed_packet。
GROUP_CONCAT为什么静默丢数据？
不是SQL写错了，也不是客户端或应用层限制——根本原因是 group_concat_max_len 默认值只有 1024 字节。超了就直接截断，不报错、不警告、不提示。你看到“明明该有 200 个 ID 却只返回前 60 个”，大概率就是它在作怪。
注意：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？
开发调试或紧急修复时，最安全的做法是只改当前连接。但必须带作用域关键字，否则 SET group_concat_max_len = 1000000 是无效的——MySQL 会静默忽略，不报错也不生效。
- 仅当前连接生效（推荐先试）：
SET SESSION group_concat_max_len = 1000000; - 对所有新连接生效（需 SUPER 权限）：
SET GLOBAL group_concat_max_len = 1000000; - 云数据库（如阿里云 RDS）通常禁用
SET GLOBAL，得去控制台改参数模板，且修改后需重启实例 - 用连接池（如 HikariCP）时，必须在初始化 SQL 里加上
SET SESSION，否则每次取连接都是默认 1024
永久生效要改配置文件，但别漏掉 max_allowed_packet
只改 group_concat_max_len 不够。如果拼接结果超过 max_allowed_packet，MySQL 会直接报错：Packet for query is too large。这个值才是真正的硬门槛。
- 查当前值：
SELECT @@max_allowed_packet;（单位字节） - 建议把
max_allowed_packet设为至少和group_concat_max_len同量级，比如都设为1048576（1MB）或更高 - 在
my.cnf的[mysqld]段下加两行：group_concat_max_len = 1048576<br>max_allowed_packet = 1048576
- 改完必须重启 MySQL：
systemctl restart mysqld或对应命令
别用 SUBSTRING 掩盖问题
SUBSTRING(GROUP_CONCAT(), 1, 50) 看起来能“控制长度”，但它是在拼完之后切——如果原始拼接已被 group_concat_max_len 截断，那切的只是那个残缺字符串。
- ❌ 错误做法：
GROUP_CONCAT(SUBSTRING(name, 1, 10))—— 这是对每个name先截再拼，不是控最终长度 - ✅ 正确顺序永远是：先确保
group_concat_max_len够大，再考虑是否需要SUBSTRING做业务层裁剪 - 真正该警惕的是：连接池复用旧会话、服务重启后参数回滚、以及 UTF-8 多字节导致的“以为够了其实不够”
