必须确认character_set_client、character_set_connection、character_set_results三个变量全为utf8mb4，任一非utf8mb4（如latin1、gbk或空值）即导致GROUP BY或GROUP_CONCAT乱码。
查清当前连接的三个关键字符集变量
GROUP BY 或 GROUP_CONCAT 出现乱码，90% 以上不是 SQL 写错了，而是连接层“说的和听的不是同一种语言”。必须立刻确认这三项是否全为 utf8mb4：
-
character_set_client：你发 SQL 时用的编码 -
character_set_connection：MySQL 接收后内部转成的编码 -
character_set_results：返回给你时用的编码
执行 SHOW VARIABLES LIKE 'character_set%';，只要其中任一项是 latin1、gbk 或空值，乱码就必然发生。别信“数据库建表时设了 utf8mb4 就够了”——GROUP_CONCAT 不看字段定义，只认这三个 session 变量。
GROUP BY 后非聚合字段显示乱码？先看 SQL_MODE
MySQL 5.7+ 默认启用 ONLY_FULL_GROUP_BY，它会让 SELECT name, COUNT(*) FROM user GROUP BY dept_id 直接报错；但若你关了它，MySQL 就会从每组里“随便挑一行”填 name。如果这一行的 name 字段本身因连接字符集错位已读成乱码，那 GROUP BY 只是把它原样带出来而已。
查当前模式：SELECT @@sql_mode;，含 ONLY_FULL_GROUP_BY 就说明问题不在分组逻辑，而在底层数据读取阶段。临时调试可运行：SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));，但更稳妥的是改写 SQL：SELECT ANY_VALUE(name), COUNT(*) FROM user GROUP BY dept_id——ANY_VALUE() 不解决乱码根源，但它让行为可预期，避免被“随机挑出”的损坏值误导。
GROUP_CONCAT 中文变问号或截断？两件事必须做
GROUP_CONCAT 的乱码和截断本质是两个独立问题，常被混为一谈：
- 变问号：说明拼接过程用了错误字符集。即使字段是
utf8mb4，只要character_set_connection不是utf8mb4，拼接时就会按 latin1 处理字节，再转成 UTF-8 就只剩 - 截断：默认
group_concat_max_len = 1024（单位是字节）。一个中文在 utf8mb4 下占 3–4 字节，实际撑不过 256 个字就截断
修复顺序不能错：先确保三个字符集变量全为 utf8mb4，再调大长度。执行 SET SESSION group_concat_max_len = 1000000;（注意是 SESSION，不是 GLOBAL），否则应用重启后失效。别用 CONVERT(GROUP_CONCAT(...) USING utf8mb4) 补救——转换发生在拼接之后，损坏已发生。
字段本身存的就是 GBK，但连接必须用 utf8mb4 怎么办？
老系统（如某些 ERP、一卡通）SQL Server 或 MySQL 用 GBK 存中文，但你又不能改库、不能换驱动，只能在应用层兜底。pymssql、JDBC 等客户端若强制设 charset='gbk'，常引发数字/符号解码异常；设 utf8 或 utf8mb4 又导致中文变 沪A12345 这类典型乱码。
正确做法是保持连接用 utf8mb4，读取后对字符串字段做中转解码：
def fix_gbk_text(s):
if isinstance(s, str):
try:
return s.encode('latin-1').decode('GBK')
except (UnicodeEncodeError, UnicodeDecodeError):
pass
return s
这个技巧依赖 latin-1 的“单字节无损映射”特性：它把每个 Unicode 码点直接当 1 字节输出，正好还原 GBK 原始字节流。但要注意——它只对原本就是 GBK 编码的字段有效；如果字段里混有 utf8mb4 和 GBK 数据，这种修复会失败，必须先统一源头。
