是group_concat_max_len导致的静默截断；需查该变量值、对比拼接前后长度、区分会话/全局作用域，并同步检查max_allowed_packet及utf8mb4字节影响。
确认是不是 group_concat_max_len 导致的静默截断
GROUP_CONCAT 不报错、不警告，但结果突然变短或中间缺内容，八成是这个参数卡住了。别靠猜，直接查：
- 执行
SHOW VARIABLES LIKE 'group_concat_max_len';，如果返回值是1024，基本坐实 - 对比两个长度：
SELECT LENGTH(GROUP_CONCAT(字段名))和SELECT SUM(LENGTH(字段名)) + (COUNT(*) - 1)（后者按默认逗号分隔估算最小字节数），前者明显小就对上了 - 注意会话级和全局级可能不同：
@@session.group_concat_max_len优先于@@global.group_concat_max_len
临时调大 group_concat_max_len 的安全写法
开发调试或线上紧急止血，用 SET SESSION 最稳妥，不影响其他连接：
- 设为 100 万字节：
SET SESSION group_concat_max_len = 1000000; - 想一步到位到理论最大值（4294967295）：
SET SESSION group_concat_max_len = -1;，MySQL 会自动转成上限 - 别用
SET GLOBAL除非你有SUPER权限，且清楚它只影响新连接——已存在的会话不会变
永久生效必须改配置，但要注意云厂商限制
生产环境重启后回退到 1024 是常见翻车点，必须落盘：
- 自建 MySQL：在
my.cnf（Linux）或my.ini（Windows）的[mysqld]段下加一行：group_concat_max_len = 1000000，然后重启mysqld - 阿里云 / 腾讯云 / AWS RDS：进控制台 → 实例参数设置 → 找到
group_concat_max_len→ 修改保存（部分需重启实例） - 云厂商通常不支持设为
-1，最大只允许到4294967295；设太大（比如10^9）可能引发内存压力，尤其在大表GROUP BY场景下
别忘了 max_allowed_packet 这个隐藏关卡
group_concat_max_len 调再大也没用，如果拼接结果超过 max_allowed_packet，查询直接失败，报错：Packets larger than max_allowed_packet are not allowed
- 检查当前值：
SHOW VARIABLES LIKE 'max_allowed_packet'; - 它默认通常是 4MB（4194304），但如果你拼的是长 JSON 或大量文本，很可能撞上
- 临时调大：
SET SESSION max_allowed_packet = 67108864;（64MB） - 永久修改同样要加到配置文件，并与
group_concat_max_len协同调整
真正容易被忽略的是字节 vs 字符——utf8mb4 下一个 emoji 或汉字占 4 字节，LENGTH() 才是真实依据，CHAR_LENGTH() 会误判。还有排序子句 ORDER BY 在 GROUP_CONCAT 内部执行，大数据量时拖慢的不是长度，而是 CPU。
