MySQL GROUP_CONCAT 结果被截断：先查实际连接的长度上限

MySQL 的 GROUP_CONCAT() 查询能执行，拼接结果却在中途结束；管理工具显示视图列是 VARCHAR，于是准备扩大字段类型。先检查执行查询的连接所用 group_concat_max_len。聚合生成结果时就可能被截断，扩大原表字段或界面显示宽度不会补回这部分内容。

下面按 MySQL 8.4 的普通服务端规则说明。默认上限是 1024 字节，实例可能已经调整；HeatWave 还有自己的列长度限制，不应直接套用普通服务端的扩大方式。

在同一连接核对限制与告警

先在实际查询连接上做只读检查：

SELECT @@session.group_concat_max_len,
       @@global.group_concat_max_len,
       @@session.max_allowed_packet;

应用使用连接池时，在另一个管理终端查到的会话值不能代表业务连接。需要核对报错或结果缺失的那次查询落在哪个实例、哪个连接，以及连接初始化有没有覆盖设置。

执行原查询后，立即在同一会话查看：

SHOW WARNINGS;

不要先执行其他普通查询再看告警，它可能替换上一条语句的诊断信息。出现与 GROUP_CONCAT 截断有关的告警时，说明应先检查聚合生成阶段；没有告警也不能单凭界面中少了几个字就断定限制有效，应继续核对完整结果、客户端显示设置和查询过滤条件。

上限按字节计算，中文等多字节字符不能按字符数估算。可在受控数据中用 OCTET_LENGTH() 检查结果字节数，配合原始行数和预期内容判断；不同字符集下同样字符数占用的字节数可能不同。视图的列类型显示不是服务器实际会话上限的替代证据。

只为需要的查询调整会话值

确认结果确实超过限制后，估算包含分隔符在内的最大结果长度，给这条业务路径留合理余量。下面是临时设为 8192 字节的示例，并在完成后恢复原值；所有操作应使用同一个连接：

SET @previous_group_concat_max_len = @@session.group_concat_max_len;
SET SESSION group_concat_max_len = 8192;

-- 在这里执行已经确认的聚合查询，再立即 SHOW WARNINGS

SET SESSION group_concat_max_len = @previous_group_concat_max_len;

示例数值不保证适合你的数据。失败路径也需要恢复设置，不能在连接回池后让后续业务继承临时状态；实际应用应由连接管理代码在明确的作用范围内设置并清理。若选择每次借出连接都初始化，应检查整个池的真实值与性能影响。

SET SESSION 只影响当前会话。调整全局默认值也不会替已经存在的连接自动更新该值；长期修改应由数据库管理流程评估，并保存原设置，不必为一次查询先重启数据库。

调得过大可能增加内存压力甚至导致 OOM。结果的有效上限还受 max_allowed_packet 约束，不能把 group_concat_max_len 设成极大值就认为不再有限制；但也不要在尚未达到通信上限时，把扩大 packet 当作聚合截断的第一步。

保留查询语义，再检查剩余缺失

GROUP_CONCAT 会忽略 NULL；DISTINCT 会去掉重复值，筛选和连接条件也决定哪些行进入聚合。调整长度后仍少内容时，先核对这些条件，不能把所有缺失都归成截断。

排序决定拼接顺序，删除 ORDER BY 可能改变业务结果。不要为了界面里出现完整字符串而无依据地取消排序或改 GROUP BY。也不要直接把视图中的表达式当作可通过 ALTER COLUMN 扩大的普通存储列。

如果聚合结果已经非常大，评估是否确实需要把全部数据塞进一个字段。分页或逐行返回能避免持续扩大单个结果，但属于接口变化，必须核对调用方，不能仅在数据库层替换返回形式。

验收时，在业务实际连接上确认上限、检查查询后的告警，比较预期条目、顺序、分隔符及最终字节数，同时确认临时设置已经恢复。若异常来自客户端显示截断，应修正显示或导出路径，不继续提高服务端内存需求。代码和会话设置回退不会恢复已经保存到其他表中的旧截断结果，相关派生数据需另行核对。