关联查询乱码主因是连接层与表字段字符集未对齐；须确保character_set_client、character_set_connection、character_set_results三者均为utf8mb4，并在连接字符串中显式指定charset=utf8mb4，而非仅修改表结构。
关联查询出现乱码，大概率不是SQL写错了，而是连接层和表字段的字符集根本没对齐。 即使两表字段都声明为 utf8mb4，只要连接时 character_set_client 或 character_set_connection 是 latin1 或 gbk，MySQL 就会在解析 JOIN 条件前强行做一次错误转码，结果就是匹配失败、返回空、或者中文变问号/ Mojibake（如 “æ人”）。
查当前连接实际生效的字符集
别信配置文件或建表语句里写的“默认值”，执行这条命令看真实状态：
SHOW VARIABLES LIKE 'character_set%';
重点关注三列：
-
character_set_client：客户端发过来的 SQL 字节流按什么编码解释 -
character_set_connection：MySQL 内部做字符串转换时用的中间编码 -
character_set_results：返回给客户端的结果用什么编码打包
只要其中任一项不是 utf8mb4，关联字段含中文时就极可能出问题。比如 character_set_client=latin1 但表字段是 utf8mb4，MySQL 会先把你的中文条件当成 latin1 字节去匹配 utf8mb4 字段——自然对不上。
连接字符串漏掉 charset 参数是最常见原因
很多驱动默认不发 SET NAMES，也不会自动协商字符集。现象是：Navicat 里手动执行 SQL 正常，程序里一跑就乱码。
- Python +
pymysql：必须显式传charset='utf8mb4'，只写charset='utf8'不行（MySQL 的utf8是阉割版） - Java + JDBC：URL 必须带
?useUnicode=true&characterEncoding=utf8mb4，注意是&不是&（XML/properties 里要转义） - PHP + PDO：DSN 中加
;charset=utf8mb4，mysqli 则要在connect()后立刻调用set_charset('utf8mb4') - 命令行导入：
mysql --default-character-set=utf8mb4 -u root -p，不加这个参数，默认走latin1
ALTER TABLE CONVERT TO 并不能修复连接层乱码
有人试过把表全改成 utf8mb4 还是乱码，就是因为只改了存储层，没动连接层。这种操作还容易踩坑：
-
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci会锁表，大数据量直接阻塞业务 - 它改的是整张表所有字段，可能误伤原本就正确的字段（比如 JSON 类型字段不需要 collation）
- 即使表改完了，如果应用连接还是用
latin1，查询结果照样是乱的
真正该优先做的，是确认并固定连接字符串里的 charset 参数，再验证 SHOW VARIABLES 三值是否全为 utf8mb4。表结构改造只是补救手段，不是第一反应。
GROUP BY 或视图里乱码，本质也是同一类问题
GROUP BY 出现中文分组错位、视图查出来是问号，都不是语法问题。它们都依赖字符串比较和排序，而 MySQL 做这些操作时，用的就是 character_set_connection 和字段自身的 collation。如果两者不匹配，比如字段是 utf8mb4_0900_as_cs，但连接层是 utf8mb4_unicode_ci，比较逻辑就可能不一致——轻则分组不准，重则触发 Illegal mix of collations 错误。
最容易被忽略的一点：collation 不等于 character set。两个字段都是 utf8mb4，但一个是 utf8mb4_general_ci（已弃用），另一个是 utf8mb4_0900_as_cs，照样报错。查字段校对规则得用 SHOW FULL COLUMNS FROM t LIKE 'col_name'，看 Collation 列，不是只扫一眼 CHARACTER SET。
