GROUP_CONCAT()必须配合GROUP BY才能按业务逻辑分组拼接，否则默认将全表视为一个隐式分组；它忽略NULL值，超长时静默截断，默认长度1024字节，需显式设置group_concat_max_len。
GROUP_CONCAT() 必须配合 GROUP BY 吗？
不必须，但绝大多数场景下应该加。不写 GROUP BY 时，GROUP_CONCAT() 会把整张表当作一个隐式分组，返回单行结果 —— 这容易被误用成“全表拼接工具”，实则仍会扫描全表、且无法按业务逻辑分区。
- 适合场景：生成全局标签列表、导出所有 ID 字符串、简单枚举去重（如
SELECT GROUP_CONCAT(DISTINCT status) FROM orders） - 风险点：若 WHERE 条件过滤后无数据，或所有值都是
NULL，函数直接返回NULL，不是空字符串，应用层判空要小心 - 别指望它替代子查询：比如想先查出每个部门的 top3 员工再拼接，不能靠
GROUP_CONCAT()内部排序解决，得先用窗口函数或 LIMIT 子句筛出行，再聚合
拼出来只有前几个值？大概率是 group_concat_max_len 截断了
GROUP_CONCAT() 默认只允许 1024 字节输出，不是字符数。UTF8mb4 下一个中文占 4 字节，1024 实际撑不了 256 个汉字；含 emoji 或长字段时更易无声截断 —— 查出来的结果“莫名其妙变短”，八成是这个原因。
- 查当前限制：
SELECT @@session.group_concat_max_len; - 临时调大（当前连接有效）：
SET SESSION group_concat_max_len = 4096;（注意单位是字节） - 别在一条 SQL 里写
SET+SELECT：MySQL 不支持语句内动态改系统变量，必须分两步执行 - 永久修改需改
my.cnf并重启，生产环境慎用；建议优先在应用层连接初始化时统一执行SET SESSION
DISTINCT、ORDER BY、SEPARATOR 的顺序和写法有硬要求
这三个修饰项不是可选开关，而是语法组成部分，位置错一个就报错。正确顺序只能是：DISTINCT → ORDER BY → SEPARATOR，且都必须写在 GROUP_CONCAT() 的括号内、字段表达式之后。
- 去重写法：
GROUP_CONCAT(DISTINCT user_name)，不是GROUP_CONCAT(DISTINCT(user_name)) - 排序字段只能是本表字段或表达式，不能用别名，也不能跨 JOIN 表直接引用（如想按订单时间排序商品名，得先
JOIN订单表，再在GROUP_CONCAT()里写ORDER BY order_time DESC） -
SEPARATOR后必须跟字符串字面量，如SEPARATOR ' | '；设为空字符串得写SEPARATOR ''，不能写SEPARATOR NULL或漏掉引号
JOIN 后 GROUP_CONCAT 拼出重复值？不是函数问题，是笛卡尔积导致的
多表关联后直接 GROUP BY 并用 GROUP_CONCAT()，常见翻车点是商品名、技能名反复出现多次。这不是函数 bug，而是 JOIN 放大了原始行数，而 GROUP_CONCAT() 是对“物理行”逐行取值拼接，不是对“逻辑实体”自动去重。
- 典型场景：用户表 × 订单表 × 订单明细表，一个用户多个订单、每个订单多个商品 →
GROUP_CONCAT(product_name)把同一商品名按订单次数重复拼入 - 解法一（推荐）：先对明细层聚合，再 JOIN 主表，例如：
SELECT u.id, u.name, t.products FROM users u LEFT JOIN (SELECT user_id, GROUP_CONCAT(DISTINCT product_name) AS products FROM orders o JOIN order_items i ON o.id = i.order_id GROUP BY user_id) t ON u.id = t.user_id - 解法二：用
DISTINCT强制去重，但掩盖了数据模型问题，排查性能或语义错误更难
NULL 值会被静默跳过，整组全 NULL 则返回 NULL；而 SEPARATOR 不处理转义，字段里若有逗号或单引号，导出后解析可能崩。这些都不是配置能一键修好的，得结合业务判断是否提前用 COALESCE()、REPLACE() 或应用层兜底。 
