GROUP_CONCAT默认截断不报错是设计行为，因group_concat_max_len默认仅1024字节，超长部分静默丢弃；需同步调大max_allowed_packet并按字节估算安全值，避免内存溢出或查询失败。
GROUP_CONCAT 默认截断不报错，不是 bug，是设计行为；但它的 1024 字节限制极易导致数据丢失，且毫无提示。
GROUP_CONCAT 被静默截断的典型现象
执行 GROUP_CONCAT 后，结果看起来“少了一半”“突然中断”“最后几个 ID 没了”，但查询不报错、日志无警告、返回状态码仍是 0。你用 LENGTH(GROUP_CONCAT(...)) 一查，发现永远卡在 1024 或略高（比如 1023），这就是默认限制生效了。
常见触发场景：
- 拼接超过 20 个 UTF-8 中文字段（每个约 3–10 字节 + 分隔符）
- 关联查询中拼接 JSON 片段或 URL 列表
- 用子查询方式写
(SELECT GROUP_CONCAT(...) FROM ...)，更容易踩坑
为什么必须同时检查 max_allowed_packet
group_concat_max_len 再大也跨不过 max_allowed_packet 这道硬门槛。后者控制 MySQL 单次网络包最大尺寸，GROUP_CONCAT 的结果作为查询返回值，必须能装进这个 packet。
如果设了 SET SESSION group_concat_max_len = 5000000，但 @@max_allowed_packet 只有 4194304（4MB），查询会直接失败，报错：Packet for query is too large。
所以务必同步确认并调整：
- 查当前值：
SELECT @@session.max_allowed_packet, @@session.group_concat_max_len; - 会话级调大：
SET SESSION max_allowed_packet = 8388608;（注意：部分客户端驱动需额外配置，如 JDBC 加maxAllowedPacket=8388608） - 云数据库（如阿里云 RDS）通常禁止运行时改
max_allowed_packet，只能通过控制台参数模板修改
SET SESSION 不生效的三个高频原因
写了 SET group_concat_max_len = 1000000 却没用？大概率掉进了这些坑：
- 漏写作用域关键字：
SET默认不生效，必须明确写成SET SESSION group_concat_max_len = ...或SET GLOBAL group_concat_max_len = ... - 连接池复用旧连接：HikariCP、Druid 等连接池取到的连接可能已初始化完毕，未执行过
SET SESSION；应在连接池connection-init-sql中配置 - 权限不足：
SET GLOBAL需要SUPER权限，而多数应用账号只有 DML 权限；云数据库通常禁用GLOBAL修改，只允许控制台调整
动态计算安全值比硬设 10M 更可靠
盲目把 group_concat_max_len 设成 10MB，可能引发内存溢出或拖慢整个查询——MySQL 会在内存中一次性加载所有待拼接值。
更稳妥的做法是按实际数据特征估算：
- 字段平均长度：
SELECT AVG(LENGTH(extra)) FROM credit.apply WHERE extra IS NOT NULL; - 单组最大行数：
SELECT MAX(cnt) FROM (SELECT custid, COUNT(*) AS cnt FROM credit.apply GROUP BY custid) t; - 安全公式（字节）：
(平均长度 × 最大行数) + (分隔符长度 × (最大行数 − 1)) + 200（+200 是缓冲） - 再拿这个结果和
@@max_allowed_packet对比，取二者较小值作为最终设置
真正容易被忽略的是：UTF-8 下中文算 3 字节，emoji 可能占 4 字节，LENGTH() 返回的是字节数而非字符数——用 CHAR_LENGTH() 会误判。
