group_concat结果被截断主因是group_concat_max_len默认值1024字节（非字符），utf-8中文占3字节，实际容量更小；需用length()验证真实长度，优先set session调大，生产环境可配my.cnf并同步检查max_allowed_packet。
GROUP_CONCAT结果被截断，不是数据丢了，是MySQL主动砍的——默认只让拼1024字节，超了静默丢弃，连警告都没有。
查当前group_concat_max_len值
先确认是不是这个参数在作祟：SELECT @@group_concat_max_len;。返回1024就坐实了问题。注意单位是字节，不是字符；UTF-8中文一个字占3字节，实际能拼的字符数远少于1024。
- 如果返回值很小（比如1024），基本就是它
- 如果返回值很大但还是截断，接着查
@@max_allowed_packet，因为即使group_concat_max_len设得再大，超过max_allowed_packet也会直接报错：Packet for query is too large - 别依赖客户端显示判断——Navicat、DBeaver等工具可能缓存或截断显示，用
LENGTH()函数验证真实长度：SELECT LENGTH(GROUP_CONCAT(name)) FROM users GROUP BY dept;
临时调大group_concat_max_len（开发/调试常用）
执行SET SESSION group_concat_max_len = 1000000;后，当前连接内所有后续查询生效。这是最安全、最常用的干预方式。
- 必须在
SELECT之前执行，不能写在同一语句里 - 数值建议按业务最大预期长度略留余量，比如预估最长拼接结果约20KB，设成30000就够了，别无脑设
18446744073709551615——容易触发内存压力甚至OOM - 重启连接后失效，适合单次排查或脚本临时运行
永久修改配置（生产环境需谨慎）
编辑MySQL配置文件my.cnf，在[mysqld]段落下添加：group_concat_max_len = 1000000，然后重启MySQL服务。
- 改完必须重启，
SET GLOBAL虽能生效但不持久，且部分托管数据库（如阿里云RDS、AWS RDS）禁止该操作 - 同步检查
max_allowed_packet是否足够，它通常默认4MB，若拼接结果接近或超过此值，需一并调大 - 上线前务必压测：用真实数据量+分组维度跑一遍，观察内存占用和查询延迟
用SUBSTRING兜底，但顺序不能错
如果无法调参（比如只读权限），又必须控制最终输出长度，只能在GROUP_CONCAT外层套SUBSTRING：SELECT SUBSTRING(GROUP_CONCAT(name SEPARATOR ', '), 1, 200) AS names...
- ❌ 错误写法：
GROUP_CONCAT(SUBSTRING(name, 1, 10))——这是对每个name先截10字符再拼，不是控制总长 - ✅ 正确顺序：先
GROUP_CONCAT完整拼，再SUBSTRING切，但前提是内部没被group_concat_max_len提前截过 - ORDER BY会影响被截位置：比如
GROUP_CONCAT(name ORDER BY id DESC)，截断会丢掉最新几条，而不是随机丢——这点常被忽略
真正麻烦的不是调参数，而是截断不报错。你看到的“数据变短了”，大概率已经丢了，只是没人告诉你。上线前一定要用LENGTH()验证拼接结果是否符合预期长度下限。
