GROUP_CONCAT是MySQL唯一原生支持分组内字段合并的聚合函数，必须配合GROUP BY使用，默认按扫描顺序拼接、逗号分隔、保留重复值且跳过NULL；支持DISTINCT去重、ORDER BY排序（限本字段）、SEPARATOR自定义分隔符，但受group_concat_max_len长度限制易静默截断。
GROUP_CONCAT 是 MySQL 唯一原生支持分组内字段合并的聚合函数，不用它就得在应用层循环拼接——多一次网络往返、多一层逻辑、多一个出错点。
GROUP_CONCAT 基本用法和默认行为
不加任何修饰时，GROUP_CONCAT(field) 会把每个分组内所有原始行的 field 值按**物理顺序**（即查询执行时扫描顺序）拼接，用英文逗号 , 分隔，且保留重复值。
常见错误现象：结果里出现重复产品名、顺序混乱、末尾莫名多出逗号（其实是字段值本身含逗号，GROUP_CONCAT 不做转义）。
- 默认分隔符不可省略，写成
GROUP_CONCAT(name SEPARATOR ',')和GROUP_CONCAT(name)效果一样 - 排序不是“自然顺序”而是“存储引擎返回顺序”，不同 MySQL 版本或执行计划下可能不一致
- 若字段为
NULL，该值直接被跳过，不会生成空字符串
去重、排序、自定义分隔符必须一起配对使用
DISTINCT 必须紧贴字段名后，ORDER BY 只能作用于当前字段（不能引用别名或 JOIN 表的字段），SEPARATOR 后必须是字符串字面量，三者位置固定、不可互换。
典型错误写法：GROUP_CONCAT(DISTINCT(name) ORDER BY create_time) —— 括号非法，create_time 未出现在分组维度中也不允许排序。
- 正确写法示例：
GROUP_CONCAT(DISTINCT product ORDER BY product ASC SEPARATOR '; ') - 想按时间排序？得先在子查询或 JOIN 中把时间字段拉进来，再对它
ORDER BY - 分隔符设为空字符串：
SEPARATOR ''，不是SEPARATOR NULL或留空
JOIN 场景下 GROUP_CONCAT 重复拼接的根本原因与解法
当 orders JOIN order_items 后直接 GROUP BY order_id 并 GROUP_CONCAT(product_name)，如果一个订单有 3 个商品、关联了 2 条优惠券记录，就会产生 3×2=6 行，导致商品名被重复拼接 2 次。
这不是函数 bug，而是 SQL 执行模型决定的：GROUP_CONCAT 聚合的是「当前结果集里的每一行」，不是「业务意义上的唯一商品」。
- 最稳解法：用子查询先聚合明细，再 JOIN。例如：
(SELECT order_id, GROUP_CONCAT(DISTINCT product_name) FROM order_items GROUP BY order_id) AS items - 临时缓解：加
DISTINCT能压掉完全相同的重复，但无法解决因关联放大导致的逻辑重复 - 避免在复杂多表 JOIN 的主查询里直接套
GROUP_CONCAT，优先拆成两步
长度截断问题和 group_concat_max_len 设置
默认 group_concat_max_len = 1024 字节，超长内容会被静默截断——查不出错，但数据不全，线上最容易被忽略。
执行 SHOW VARIABLES LIKE 'group_concat%'; 就能看到当前值；导出报表或拼接长标签列表前务必确认。
- 会话级修改：
SET SESSION group_concat_max_len = 10000;（推荐，不影响其他连接） - 全局修改需重启或
SET GLOBAL，生产环境慎用 - 配置文件中设置：
group_concat_max_len = 10000，需重启 MySQL 生效 -
LIMIT在含GROUP_CONCAT的查询中无效，别指望靠它控制拼接项数
真正麻烦的从来不是语法怎么写，而是你不知道结果被截断了、排序乱了、或者 JOIN 放大后拼出来一堆重复——这些都得结合执行计划和原始行数交叉验证，不能只看最终输出。
