group_concat结果被截断是因group_concat_max_len默认仅1024，需调大；null值默认被忽略，可用ifnull处理；排序和去重须显式声明；join时易引发性能问题，慎用于大数据量拼接。
GROUP_CONCAT 为什么拼出来的结果被截断了
默认只返回前 1024 个字符，超出部分直接丢弃，不是报错，所以容易误以为数据“没了”。根本原因是服务端变量 group_concat_max_len 太小。
- 查当前值：
SELECT @@group_concat_max_len; - 临时改（当前会话有效）：
SET SESSION group_concat_max_len = 1000000; - 永久改需在 my.cnf 里加：
group_concat_max_len = 1000000，然后重启 MySQL - 注意：这个值不能超过
max_allowed_packet，否则执行时会静默失败
GROUP_CONCAT 拼接字段含 NULL 时怎么处理
NULL 值默认不参与拼接，也不会占一个空位——它直接消失。比如 GROUP_CONCAT(name) 遇到 name 是 NULL 的行，那行就彻底没影了，不是变成空字符串。
- 想把 NULL 显式转成字符串（如
'(unknown)'），得用IFNULL()或COALESCE()：GROUP_CONCAT(IFNULL(name, '(unknown)')) - 如果想保留 NULL 占位（比如为了对齐或调试），只能先用
CONCAT()转成非 NULL 字符串，再进GROUP_CONCAT - 别依赖
GROUP_CONCAT自动处理 NULL，它不负责兜底
GROUP_CONCAT 排序和去重必须显式写出来
它不会自动按主键、时间或任何字段排序，也不去重——哪怕你 GROUP BY id，里面拼的值还是原始顺序（通常是引擎返回顺序，不可靠）。
- 要排序：写在函数内部，用
ORDER BY子句：GROUP_CONCAT(name ORDER BY created_at DESC) - 要去重：加
DISTINCT关键字：GROUP_CONCAT(DISTINCT status) - 两者可以共存：
GROUP_CONCAT(DISTINCT name ORDER BY name ASC) - 注意：
ORDER BY里不能引用别名，只能用原始列名或表达式
GROUP_CONCAT 和 JOIN 一起用时的性能陷阱
很多人用 GROUP_CONCAT 替代子查询或多次查询，但若配合多表 JOIN，尤其 LEFT JOIN 后有 1:N 关系，会导致中间结果集爆炸，GROUP_CONCAT 反而成为性能瓶颈。
- 典型症状：查询变慢、内存占用飙升、甚至触发
sort_buffer_size不足警告 - 验证方法：先去掉
GROUP_CONCAT，用COUNT(*)看 JOIN 后总行数是否远超预期 - 更稳的替代思路：先聚合（用子查询或 CTE 把 N 侧收拢），再 JOIN；或者应用层分两步查
-
GROUP_CONCAT适合轻量拼接（几十到几百个值），不适合拼上千条记录
group_concat_max_len 的会话级设置——开发在本地设了，上线忘了配，线上一跑就丢数据，还很难复现。
