GROUP_CONCAT默认截断因group_concat_max_len过小，需调大该值及max_allowed_packet，并注意UTF8MB4下字节数与字符数差异。
GROUP_CONCAT 默认截断不报错，必须主动调大 group_concat_max_len 才能保数据完整。
查当前限制值，确认是否已踩坑
执行 SELECT @@session.group_concat_max_len, @@global.group_concat_max_len; 看两个值。如果都是 1024，那几乎可以确定你遇到的“结果突然变短”“明明有 500 条却只拼出前几十条”就是它干的。
注意：@@session 是当前连接生效的值，@@global 是新连接默认值。有些应用用连接池，每次取连接都走默认 session 值，所以光改 global 不一定管用。
- 云数据库（如阿里云 RDS）可能禁用
SET GLOBAL，得去控制台参数模板里改 - 执行
SHOW VARIABLES LIKE 'group_concat_max_len';也能查，但返回的是字符串，不如直接查系统变量直观
临时修复：会话级 SET 最快见效
在业务 SQL 执行前加一句：SET SESSION group_concat_max_len = 1000000;（建议设到 100 万字节以上）
这个操作立即生效，且只影响当前连接，适合紧急止血或测试验证。
- 别漏写
SESSION，只写SET group_concat_max_len = ...MySQL 会静默忽略 - 如果用 JDBC，可在连接 URL 里加
sessionVariables=group_concat_max_len=1000000，避免每次手动 SET - HikariCP 等连接池支持
connection-init-sql，把这句塞进去最稳妥
永久生效：配 my.cnf + 注意 max_allowed_packet
在 my.cnf 的 [mysqld] 段下加：group_concat_max_len = 1000000，然后重启 MySQL。
但光调这个不够——GROUP_CONCAT 结果要作为查询返回值发给客户端，还得跨过另一道关：max_allowed_packet。
- 查它：
SELECT @@max_allowed_packet;，单位是字节 - 如果
group_concat_max_len设成 5M，但max_allowed_packet只有 4M，查询会直接报错Packet for query is too large - 两者需同步调大，且客户端驱动（如 JDBC）也要支持接收大包，比如加
maxAllowedPacket=5242880
拼太长时，别硬刚 GROUP_CONCAT
当拼接内容动辄几万字符、含 JSON 或需要去重/条件过滤/空值跳过时，GROUP_CONCAT 就开始不可靠了：
- 它不能跳过
NULL，得显式写IFNULL(col, '') - 不支持“只拼 status=1 的记录”，得套
CASE WHEN - MySQL 5.7+ 推荐用
JSON_ARRAYAGG替代，天然无长度硬限制、类型安全、支持嵌套 - 若下游要解析拼接结果，或字段本身含逗号/反斜杠，优先考虑应用层聚合，更可控
真正容易被忽略的点是：group_concat_max_len 控制的是字节数，不是字符数；UTF8MB4 下一个 emoji 或中文占 4 字节，1024 字节撑不了多少内容——别按“字符个数”去估算，得按实际字节长度算。
