GROUP_CONCAT结果被截断是因group_concat_max_len默认1024字节，需按会话、全局或配置文件调整；同时受max_allowed_packet限制，且存在内存与性能风险。
GROUP_CONCAT 返回结果被截断怎么办
MySQL 的 GROUP_CONCAT 默认只返回最多 1024 字符，超出部分直接丢弃，不会报错，但数据不全——这是最常被忽略的“静默截断”问题。比如你拼接几百个 ID 或 JSON 片段，结果突然变短、少了一半，大概率就是这个原因。
根本原因是服务端变量 group_concat_max_len 的默认值太小。它控制单次 GROUP_CONCAT 聚合结果的最大字节数（注意：是字节，不是字符；UTF-8 下中文占 3 字节）。
- 会话级修改（当前连接生效）：
SET SESSION group_concat_max_len = 1000000; - 全局级修改（新连接生效，需 SUPER 权限）：
SET GLOBAL group_concat_max_len = 1000000; - 永久生效需写入配置文件：
group_concat_max_len = 1000000加到my.cnf的[mysqld]段下
为什么 SET SESSION 不生效或重启后失效
常见误操作是只执行了 SET group_concat_max_len = ...，漏掉 SESSION 或 GLOBAL 作用域关键字，MySQL 会静默忽略（不报错但也不生效）。另外，某些云数据库（如阿里云 RDS、腾讯云 CDB）禁止运行时修改 GLOBAL 变量，只能通过控制台参数模板调整，且修改后需重启实例才生效。
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
- 确认当前值：
SELECT @@session.group_concat_max_len;或SELECT @@global.group_concat_max_len; - 云环境优先查控制台「参数设置」页，搜索
group_concat_max_len - 若用连接池（如 HikariCP），确保初始化 SQL 中包含
SET SESSION，否则每次取连接都可能是默认值
GROUP_CONCAT 和 max_allowed_packet 的关系
group_concat_max_len 再大，也跨不过 max_allowed_packet 这道硬门槛。后者限制服务器能接收/发送的单个 packet 大小，GROUP_CONCAT 结果作为查询返回值，必须装得进这个 packet。如果拼接结果超过 max_allowed_packet，会直接报错：Packet for query is too large。
- 检查当前值：
SELECT @@max_allowed_packet;（单位是字节） - 若
group_concat_max_len设为 5M，但max_allowed_packet只有 4M，则仍会失败 - 两者需协同调大，且
max_allowed_packet修改后，客户端连接也要支持接收大包（如 JDBC URL 加maxAllowedPacket=5242880）
拼接大量数据时的性能与内存风险
盲目把 group_concat_max_len 设到 100M 并不安全。MySQL 在执行 GROUP_CONCAT 时，会把所有匹配行的字段值先加载进内存再拼接，数据量大时极易触发 Out of memory 或显著拖慢查询。尤其在 GROUP BY 多字段、源表行数上万时，风险陡增。
- 优先考虑替代方案：应用层分批拉取 + 拼接，或改用 JSON 函数（如
JSON_ARRAYAGG，MySQL 5.7+，支持流式序列化） - 必须用
GROUP_CONCAT时，加ORDER BY明确排序，并用SEPARATOR控制分隔符长度（避免用长字符串做分隔符） - 监控
Handler_read_rnd_next和临时表使用量，异常升高说明聚合过程压力过大
真正麻烦的不是设多大，而是没意识到它背后绑着内存、网络包、连接生命周期三根线——调一个参数前，得先看清哪根线已经绷紧了。
