GROUP_CONCAT会因group_concat_max_len默认1024字符限制而 silently 截断数据；需检查并调大该值，且ORDER BY和SEPARATOR必须置于函数括号内；去重须用DISTINCT；MySQL 8.0.17+推荐用JSON_AGG替代以避免转义和解析问题。
GROUP_CONCAT 会丢数据？检查 group_concat_max_len 限制
默认情况下，GROUP_CONCAT 最多只返回 1024 个字符，超出部分直接截断，且不报错——这是最常被忽略的数据丢失原因。
- 查当前限制：
SELECT @@group_concat_max_len; - 临时调大（当前会话有效）：
SET SESSION group_concat_max_len = 1000000; - 永久生效需修改 MySQL 配置文件中的
group_concat_max_len值，并重启服务 - 注意：该参数影响所有使用
GROUP_CONCAT的查询，不是单条语句的局部设置
ORDER BY 和 SEPARATOR 必须写在括号内，位置错了就失效
GROUP_CONCAT 的排序和分隔符必须作为函数内部参数，写在括号里；放在 GROUP BY 后或 ORDER BY 子句里完全无效。
- 正确写法：
GROUP_CONCAT(name ORDER BY id SEPARATOR '; ') - 错误写法：
GROUP_CONCAT(name) ORDER BY id（这只会对整个结果集排序，不影响拼接顺序） - 省略
SEPARATOR时默认用逗号，但逗号容易和字段值里的逗号混淆，显式指定更安全 - 如果字段含空值（
NULL），GROUP_CONCAT默认跳过，无需额外处理
去重合并要用 DISTINCT，别指望 GROUP BY 替代
GROUP BY 控制的是分组粒度，不影响 GROUP_CONCAT 内部是否去重；要避免重复值，必须在函数里用 DISTINCT。
- 去重拼接：
GROUP_CONCAT(DISTINCT tag_name ORDER BY tag_name) - 不加
DISTINCT即使分组后每行值相同，也会原样拼进去 -
DISTINCT和ORDER BY可共存，但ORDER BY必须作用于去重后的结果 - 性能提示：大量数据去重 + 排序会使
GROUP_CONCAT变慢，必要时考虑应用层聚合
MySQL 8.0+ 有更好替代？JSON_AGG 更适合结构化拼接
如果目标是生成结构化数据（比如数组或对象），JSON_AGG 比 GROUP_CONCAT 更可靠，尤其当字段含特殊字符、引号或需要嵌套时。
- 简单数组：
JSON_AGG(name)→["Alice","Bob"] - 带键对象：
JSON_OBJECT('id', id, 'name', name)配合JSON_AGG可生成对象列表 -
GROUP_CONCAT输出纯字符串，解析需额外 split 或正则，易出错；JSON_AGG返回标准 JSON，客户端可直接解析 - 注意：
JSON_AGG是 MySQL 8.0.17+ 才支持，低版本只能硬扛GROUP_CONCAT的各种转义坑
group_concat_max_len + 显式 SEPARATOR 就够用；要是传给前端做列表渲染，或者字段内容不可控，JSON_AGG 真的省心很多。 
