确认group_concat结果截断是否由group_concat_max_len引起：先查select @@session.group_concat_max_len，再用select length(group_concat(your_column))对比字节数，若后者明显更大即为此因。
GROUP_CONCAT结果无声截断，怎么确认是group_concat_max_len惹的祸？
不是SQL写错了，也不是客户端显示问题，而是MySQL在你眼皮底下把超长结果直接丢掉——还不报错。最快速的验证方式是两步：SELECT @@session.group_concat_max_len查当前会话值；再用SELECT LENGTH(GROUP_CONCAT(your_column))看实际拼出多少字节。如果后者明显大于前者，就是它了。
注意：LENGTH()返回的是字节数，不是字符数；UTF-8下中文、emoji、路径里的斜杠都算1字节，但一个汉字占3字节，别拿字符数去比。
常见误判点：
- 在Navicat里看到结果变短，第一反应是客户端限制 —— 但直接
SELECT '一长串中文...'能完整显示，就排除客户端 - 以为加了
ORDER BY或DISTINCT能绕过限制 —— 它们不改变长度上限 - 用
CHAR_LENGTH()对比 —— 错，group_concat_max_len只认字节
临时修复：SET SESSION必须带作用域关键字
紧急上线或调试时，执行SET SESSION group_concat_max_len = 102400是最安全的止血操作。它只影响当前连接，不影响其他会话，也不需要重启服务。
但容易踩坑：
- 漏写
SESSION（比如只写SET group_concat_max_len = 102400）—— MySQL静默忽略，你以为改了，其实没生效 - 在连接池环境（如HikariCP、Druid）里只执行一次 —— 连接复用后，新取的连接仍是默认值，得在连接初始化SQL里配置
- 设完不验证 —— 务必跟一句
SELECT @@session.group_concat_max_len确认是否真改成功
永久生效：my.cnf里加配置，但要注意max_allowed_packet
生产环境必须改配置文件，否则服务重启就回滚。在my.cnf的[mysqld]段下加一行：group_concat_max_len = 102400，然后重启MySQL。
但光调大这个不够，还得看max_allowed_packet：
-
group_concat_max_len再大，也跨不过max_allowed_packet这道硬门槛 - 如果拼接结果超过
max_allowed_packet，会直接报错：Packets for query is too large - 查当前值：
SELECT @@max_allowed_packet；若你要设group_concat_max_len为5M，max_allowed_packet至少也要设为5242880（单位字节） - JDBC连接还要加参数：
?maxAllowedPacket=5242880，否则客户端收不到完整结果
设多大才够？盲目拉到最大值有风险
别一上来就SET GLOBAL group_concat_max_len = 18446744073709551615。这个理论最大值看着爽，但实际会引发两个问题：
- MySQL执行
GROUP_CONCAT时，会把所有匹配行的字段内容一次性加载进内存再拼接，数据量大时可能OOM或拖慢整条查询 - 云数据库（如阿里云RDS、腾讯云CDB）通常禁止
SET GLOBAL，只能通过控制台参数模板修改，且修改后需重启实例 - 真正该设多大，得按业务估算：
MAX(LENGTH(字段)) * 行数 + (行数 - 1) * LENGTH(分隔符)，留20%余量即可
比如每张图片URL平均55字节，最多存200张，分隔符用逗号：55 × 200 + 199 ≈ 11200字节，设成12000足够，没必要上百万。
