GROUP_CONCAT结果被无声截断是因为group_concat_max_len默认值为1024字节，超长部分直接丢弃且不报错；需通过SET SESSION或修改my.cnf调大该值，并注意max_allowed_packet限制及连接池复用旧会话问题。
GROUP_CONCAT结果被无声截断，不是你的SQL写错了，是MySQL默认只允许拼出1024字节 —— 超过就丢，不报错、不警告、不提示。
为什么GROUP_CONCAT会突然少数据？
现象很典型：单条记录查出来完整，一加GROUP BY再套GROUP_CONCAT，返回的字符串就变短了，比如该有200个ID却只显示前60个。你翻日志、看应用层、查客户端，全没异常 —— 因为问题压根不在那里。
根本原因是：group_concat_max_len这个系统变量默认值是1024（单位：字节），不是字符数，也不是行数。中文、emoji、UTF-8编码的字段会更快占满这1024字节。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用
SELECT LENGTH(GROUP_CONCAT(...))能直接看到实际字节数，和show variables like 'group_concat_max_len'对比，立刻确认是否被截 - 注意：
LENGTH()返回字节数，CHAR_LENGTH()才返回字符数；MySQL里group_concat_max_len认的是字节 - 即使你用
SEPARATOR ''或空格分隔，分隔符本身也计入长度
临时生效：用SET命令改当前会话或全局
适合开发调试、紧急修复、或你知道连接生命周期较短的场景。执行后立即起效，但重启MySQL服务就还原。
- 只改当前连接（推荐先试）：
SET SESSION group_concat_max_len = 102400; - 改所有新连接（需SUPER权限）：
SET GLOBAL group_concat_max_len = 102400; - 想一步设到理论最大值（64位系统）：
SET GLOBAL group_concat_max_len = 18446744073709551615; - 执行后务必验证：
SELECT @@session.group_concat_max_len;和SELECT @@global.group_concat_max_len;
永久生效：改MySQL配置文件
生产环境必须走这步，否则服务重启后参数回滚，问题重现。注意配置位置和权限。
- Linux下路径通常是
/etc/my.cnf或/etc/mysql/my.cnf；Windows下是my.ini - 必须加在
[mysqld]段落下，不能放在[client]或无标签区 - 添加一行：
group_concat_max_len = 102400（或你算好的安全值） - 修改后需重启MySQL：
sudo systemctl restart mysql（或mysqld） - 配置值不支持单位缩写（如k/M），只接受纯数字；也不能写
-1，MySQL不识别
还有哪些坑容易被忽略？
很多人调大了group_concat_max_len就以为万事大吉，但实际还有几个关键点卡住效果：
- 应用连接池可能复用旧连接 —— 即使你改了GLOBAL，已建立的连接仍用旧SESSION值，得让连接池重建连接或显式执行
SET SESSION - 某些ORM（如MyBatis）在XML里写
GROUP_CONCAT时，若字段含逗号、引号等特殊字符，又没用SEPARATOR控制，拼出来的字符串可能被上层错误解析 - 如果真要拼超长内容（比如导出全部用户邮箱），建议优先考虑应用层分页聚合，而不是把
group_concat_max_len设到顶 —— 过大的单行结果会拖慢网络传输和内存分配 -
GROUP_CONCAT本身不保证排序，除非显式写ORDER BY子句，否则每次执行顺序可能不同
