GROUP_CONCAT结果截断主因是group_concat_max_len默认1024字节过小，UTF-8下中文仅容约300字符；需查会话/全局值及max_allowed_packet，临时用SET SESSION修改，永久配置须改my.cnf或云平台参数模板并重启。
GROUP_CONCAT结果被截断，不是数据丢了，是group_concat_max_len默认值太小——1024字节，UTF-8下中文可能只撑住300多个字符。
怎么立刻验证是不是长度限制导致的截断
直接查当前会话和全局的设置值，别猜：
SELECT @@session.group_concat_max_len;SELECT @@global.group_concat_max_len;- 如果返回
1024，基本就是它了 - 再顺手查下
SELECT @@max_allowed_packet;，避免调大后卡在另一道门槛上
临时生效：用SET SESSION改当前连接
开发调试、脚本执行、应用初始化阶段最常用。注意必须带 SESSION 关键字，漏掉就静默失败：
-
SET SESSION group_concat_max_len = 5000000;（设为5MB，够拼接上千个ID或短文本） - 若用连接池（如 HikariCP、Druid），得在
connection-init-sql里加这句，否则每次取连接都是默认值 - 不推荐用
SET group_concat_max_len = ...（缺作用域），MySQL 不报错但也不生效
永久生效：配my.cnf还是云数据库控制台
生产环境必须持久化，但方式取决于你用的是自建 MySQL 还是云服务：
- 自建 MySQL：在
my.cnf的[mysqld]段下加一行group_concat_max_len = 5000000，然后重启mysqld - 阿里云 RDS / 腾讯云 CDB / AWS RDS：不支持
SET GLOBAL，必须进控制台「参数模板」里修改group_concat_max_len，且多数需重启实例才生效 - 改完别忘了同步检查
max_allowed_packet，比如设了group_concat_max_len = 5000000，但max_allowed_packet还是4194304（4MB），查询会直接报Packet for query is too large
拼太长反而拖垮查询：内存和临时表风险
把 group_concat_max_len 设成 100MB 并不安全。MySQL 执行时会把所有待拼接字段一次性加载进内存：
- 分组内有上万行、每行字符串几十字节 → 很容易触发
Out of memory或显著延长执行时间 - 用
DISTINCT时更危险：当结果超内存临时表上限（tmp_table_size），MySQL 自动切到磁盘临时表，而磁盘版GROUP_CONCAT(DISTINCT ...)存在已知去重失效 bug - 真要拼大量数据，优先考虑在应用层聚合，或换
JSON_ARRAYAGG()（MySQL 5.7+），它不受group_concat_max_len限制，且语义更清晰
最容易被忽略的点：group_concat_max_len 是按字节算的，不是字符；ORDER BY 必须写在 GROUP_CONCAT() 函数括号里才生效；云数据库改参后不重启=白改。
