GROUP_CONCAT静默丢数据是因为group_concat_max_len默认仅1024字节，超长部分不报错直接截断；UTF-8下中文占3~4字节，几十个字段即超限，需通过SET SESSION或配置文件调大该值，并同步检查max_allowed_packet限制。
GROUP_CONCAT为什么静默丢数据？
因为group_concat_max_len默认是1024字节，不是字符数——UTF-8下1个中文占3~4字节，拼几十个就超限；超了不报错、不警告，只悄悄砍掉后面部分。你查出来的结果“看起来正常”，但可能漏了一半ID或标签。
怎么立刻确认并调大长度限制？
先查当前值：SELECT @@session.group_concat_max_len;。如果返回1024，基本可以确定是它在作怪。
临时生效（当前连接）：SET SESSION group_concat_max_len = 1000000;
永久生效（需重启）：在my.cnf的[mysqld]段加一行：group_concat_max_len = 1000000
- 云数据库（如阿里云RDS）通常禁用
SET GLOBAL，得去控制台改参数模板 - 连接池（如HikariCP）每次取连接都是新session，必须配初始化SQL：
SET SESSION group_concat_max_len = 1000000 - 别漏写
SESSION关键字，SET group_concat_max_len = ...会被MySQL静默忽略
拼完再截 vs 每个字段先截，有什么区别？
想控制最终输出长度50字符，应该：SUBSTRING(GROUP_CONCAT(name SEPARATOR ', '), 1, 50)
而不是：GROUP_CONCAT(SUBSTRING(name, 1, 10))——这会把每个name都砍成10字符再拼，语义完全不同。
注意：如果原始GROUP_CONCAT已因group_concat_max_len被截断，SUBSTRING只能切那个残缺结果。
更稳妥的做法是先估算最大需要多少字节：SELECT MAX(CHAR_LENGTH(GROUP_CONCAT(content))) FROM t GROUP BY group_id;，再反推设置值。
别忘了max_allowed_packet这个硬门槛
group_concat_max_len再大，也跨不过max_allowed_packet。后者限制单次查询返回包大小，超了直接报错：Packets for query is too large。
检查它：SELECT @@max_allowed_packet;（单位字节）
如果设了group_concat_max_len = 5242880（5MB），但max_allowed_packet只有4MB，照样失败。
调整时两者要同步：服务端改max_allowed_packet，客户端（如JDBC）也要加参数maxAllowedPacket=5242880，否则收不到完整结果。
真正容易被忽略的是：GROUP_CONCAT在子查询里执行时，继承的是外层查询的session值，不是子查询自己能控制的；另外，盲目设到100MB以上，可能触发OOM或拖慢整个实例——长度够用就行，别堆数字。
