GROUP_CONCAT乱码的根本原因是连接层字符集（character_set_client/connection/results）非utf8mb4，导致拼接过程在错误编码下进行，即使字段本身为utf8mb4也会退化为latin1或截断；同时group_concat_max_len过小引发字节截断，加剧乱码假象。
GROUP_CONCAT 乱码的根本原因是什么
MySQL 的 GROUP_CONCAT 默认使用连接会话的 character_set_results，但若字段本身是 utf8mb4，而客户端或连接层实际以 latin1 解析，就会显示问号或 Mojibake（如 “æ些å”）。这不是拼接逻辑出错，而是字符集在“存储 → 传输 → 展示”任一环节未对齐。
用 CONVERT 显式转字符集的正确写法
不能只写 CONVERT(col USING utf8mb4) 就完事——GROUP_CONCAT 内部仍可能按旧规则拼接。必须让整个表达式在统一字符集下运算：
-
GROUP_CONCAT(CONVERT(col USING utf8mb4))是常见错误：CONVERT 作用于单值，但拼接时隐式转换仍可能发生 - 正确做法是先统一字段表达式的字符集，再传给
GROUP_CONCAT：GROUP_CONCAT(CAST(col AS CHAR CHARACTER SET utf8mb4)) - 更稳妥的是连同分隔符一起指定：
GROUP_CONCAT(CAST(col AS CHAR CHARACTER SET utf8mb4) SEPARATOR ',')
为什么 SET NAMES 不够用
SET NAMES utf8mb4 只影响后续语句的 character_set_client/character_set_connection，但已定义的列、视图或函数返回值的字符集不会自动重映射。尤其当表字段是 utf8（非 utf8mb4）且内容含 emoji 时，即使连接设对了，GROUP_CONCAT 仍可能截断或双编码。验证方式：SHOW VARIABLES LIKE 'character_set%' 看全部 5 项是否一致为 utf8mb4。
额外要检查的三个地方
乱码常不是单一环节导致：
- 建表时字段是否用了
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci？仅用utf8会丢 emoji - 连接字符串里有没有
characterEncoding=utf8mb4（JDBC）或charset=utf8mb4（PHP PDO）？光设SET NAMES不够 -
GROUP_CONCAT结果长度是否被截断？查@@group_concat_max_len，太小会导致后半截乱码（看似编码问题，实为截断）
字符集对齐是链条行为，漏掉任意一环，CONVERT 就只是在错误数据上做无用功。
