GROUP BY 乱码本质是字符集不匹配所致，需统一数据库、连接、表字段、校对规则、驱动及输出环节的 utf8mb4 编码与 utf8mb4_unicode_ci 校对。
GROUP BY 结果出现乱码，先查数据库和连接的字符集是否一致
首先得明确一点：乱码这事儿，GROUP BY 本身可不背锅。它更像一个“吹哨人”，把底层早已存在的字符集不匹配问题给暴露了出来。想想看，当 MySQL（或其他数据库）执行 GROUP BY 时，免不了要进行字符串比较、排序和聚合。如果字段实际存储用的是 utf8mb4，但客户端连接却误用了 latin1 或者干脆没声明编码，那结果出现一堆问号，或者显示成 “æ人” 这种“天书”（Mojibake），就一点儿也不奇怪了。
- 第一步，在数据库里运行
SHOW VARIABLES LIKE 'character_set%';。重点盯住character_set_database、character_set_server、character_set_client和character_set_connection这几个关键变量，确保它们清一色都是utf8mb4。 - 接着检查连接配置。比如 JDBC URL 里有没有带上
?characterEncoding=utf8mb4；用 Python 的pymysql.connect()时，是否显式传入了charset='utf8mb4'参数。 - 如果用的是 Na vicat 或 DBea ver 这类图形化工具，记得点开连接属性，确认“字符集”选项设为了
utf8mb4。这里有个常见的坑：默认的utf8选项其实是 MySQL 的“阉割版”，它不支持 emoji 和部分生僻汉字，务必避开。
SELECT 中非聚合字段被 GROUP BY 带出乱码？检查 SQL_MODE 是否启用了 ONLY_FULL_GROUP_BY
从 MySQL 5.7 版本开始，ONLY_FULL_GROUP_BY 模式默认就是开启的。这会导致一个什么情况呢？假设你写了条 SQL：SELECT name, COUNT(*) FROM user GROUP BY dept_id;，而 name 字段并没有出现在 GROUP BY 子句中。这时，MySQL 要么直接报错，要么返回一个不确定的值——如果这个 name 字段本身因为编码问题读取时就不正常，那么被 GROUP BY 随意挑出来的“任意一行值”，就更容易以乱码的面目示人了。
- 先确认当前模式：执行
SELECT @@sql_mode;，看看结果里是否包含ONLY_FULL_GROUP_BY。 - 如果想临时关闭它来调试（仅限测试环境），可以执行：
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));。但更稳妥、更规范的做法是改写 SQL 语句：使用MAX(name)或ANY_VALUE(name)来显式地告诉 MySQL 你希望如何选取这个值。 - 需要提醒的是，
ANY_VALUE()函数本身并不会改变编码行为。如果name字段里存的就是乱码数据，那这个函数也无力回天——问题的根源，终究还是落在字符集上。
GROUP BY 字段本身含中文却分组失败或显示异常？确认字段的 collation 是 utf8mb4_unicode_ci 或类似
这里涉及两个核心概念：字符集（character set）决定“能存什么字”，而校对规则（collation）则决定了“怎么比、怎么排、怎么分组”。即使表字段的字符集已经是 utf8mb4，但如果它的 collation 设置是旧版的 utf8mb4_general_ci（现已不推荐），或者是二进制的 utf8mb4_bin，都可能导致中文分组不准确。例如，“张三”和“張三”可能被当成两个不同的值，或者排序后显示错位，给人一种视觉上的“乱码感”。
- 查看字段的校对规则：执行
SHOW FULL COLUMNS FROM user LIKE 'name';，重点关注结果中的Collation这一列。 - 通常推荐统一使用
utf8mb4_unicode_ci，它在准确性和性能之间取得了较好的平衡。如果用的是 MySQL 8.0 及以上版本，也可以考虑utf8mb4_0900_as_cs（区分大小写和重音）。 - 修改语句示例：
ALTER TABLE user MODIFY name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。不过要特别注意：这类操作通常会锁表，在生产环境执行务必谨慎，最好在业务低峰期进行。
应用层拿到 GROUP BY 结果还是乱码？检查输出环节的编码链路断点
数据从数据库查询出来，到最终在网页、日志或 API 响应里正确显示，中间是一条漫长的“编码链路”。这条链路上任何一个环节出错，都可能让 GROUP BY 的干净结果“前功尽弃”。整个过程至少包括：MySQL 协议传输 → 驱动解码 → 应用内存中的字符串表示 → 输出流编码（如 HTTP 的 Content-Type、文件写入、控制台打印）。
- 对于 PHP，使用
mysqli_set_charset($conn, 'utf8mb4');来设置字符集，通常比仅仅在连接参数里设置更可靠。 - 在 Ja va 中，使用
PreparedStatement时，要确保ResultSet.getString()返回的是正确编码的 String。尽量避免使用getBytes()再手动进行new String(...)转换，这个操作极易引发二次解码错误。 - 当 Web 接口返回 JSON 数据时，HTTP 响应头必须包含
Content-Type: application/json; charset=utf-8。同时，要确保 JSON 字符串本身除了标准的 \uXXXX 转义序列外，不包含其他非 ASCII 字符。否则，前端解析时可能会错误地回退到 ISO-8859-1 编码。
说到底，真正让人头疼的往往不是 GROUP BY 的语法，而是字符集配置在连接、表定义、字段校对规则、驱动配置、HTTP 头、前端渲染这六七个环节中，恰好有那么一两处没对齐。调试时，别只盯着 SQL 语句改。一个更有效的方法是：直接抓取网络数据包，查看原始的响应字节流，甚至用 hexdump 工具分析一下。只有这样，才能精准定位到底是哪一层，错误地把 utf8mb4 编码的数据当成 latin1 给解码了。
