JOIN中文字段匹配失败的主因是character_set_client、connection、results三项字符集未统一为utf8mb4，导致SQL解析前发生错误转码；需在连接字符串中显式指定charset=utf8mb4，并验证三参数全为utf8mb4。
JOIN 条件中文字段匹配失败，先查三处字符集
JOIN 时中文字段“看起来一样却连不上”，大概率不是 SQL 写错了，而是 character_set_client、character_set_connection、character_set_results 这三项没对齐。哪怕两张表字段都定义为 utf8mb4_unicode_ci，只要其中任一连接参数是 latin1 或 gbk，MySQL 就会在解析 ON 条件前强行做一次错误转码——比如把 “张三” 的 UTF-8 字节当成 Latin-1 解，自然匹配不上。
执行 SHOW VARIABLES LIKE 'character_set%'; 看真实值，别信配置文件或建表语句里的“默认”。重点盯这三行，必须全为 utf8mb4。
-
character_set_client：你发的 SQL 字符串按什么编码读 -
character_set_connection：MySQL 内部做字符串比较时用的编码 -
character_set_results：返回结果打包时用的编码
连接字符串漏掉 charset=utf8mb4 是最常见原因
Navicat 里手动执行 JOIN 正常，程序里一跑就空结果？八成是驱动没显式声明字符集。不同语言写法差异大，但核心就一条：不能依赖“自动协商”，必须在连接初始化时硬编码指定。
- Python +
pymysql：charset='utf8mb4'必须传进pymysql.connect()，只写charset='utf8'不行（MySQL 的utf8是阉割版） - Java + JDBC：
jdbc:mysql://host/db?useUnicode=true&characterEncoding=utf8mb4，注意是&（XML/properties 里要转义），且值必须是utf8mb4，不是UTF-8 - PHP + PDO：
mysql:host=localhost;charset=utf8mb4要写在 DSN 字符串里；mysqli则必须在connect()后立刻调用set_charset('utf8mb4') - 命令行
mysql客户端：mysql --default-character-set=utf8mb4 -u root -p，不加这个参数默认走latin1
跨表 JOIN 时 COLLATE 不一致会导致隐性匹配失败
两张表同名字段都是 utf8mb4，但一个用 utf8mb4_unicode_ci，另一个是 utf8mb4_general_ci，JOIN 时可能静默降级比较逻辑——比如 “张三” 和含全角空格的 “张三 ” 被判为不等，结果漏数据。
查字段实际校对规则：SELECT COLUMN_NAME, COLLATION_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name';
- 临时验证：在 JOIN 条件里强制统一，如
ON a.name COLLATE utf8mb4_unicode_ci = b.name COLLATE utf8mb4_unicode_ci - 长期解法：建表时显式声明
name VARCHAR(50) COLLATE utf8mb4_unicode_ci NOT NULL，别靠数据库默认值 - 避免用
utf8mb4_general_ci（已废弃），中文场景优先选utf8mb4_unicode_ci或 MySQL 8.0.30+ 的utf8mb4_zh_0900_as_cs
别用 ALTER TABLE CONVERT TO 代替连接层修复
有人试过把两张表全 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 还是连不上，就是因为只改了存储层，没动连接层。这种操作本身还有风险：
- 大表执行会锁表、重建索引、吃双倍磁盘空间，线上慎用
-
CONVERT TO改的是整张表所有字段，可能误伤 JSON 类型字段（它不需要 collation） - 即使表改完了，如果应用连接还是
latin1，JOIN 条件照样被错解
真正该优先做的，是确认并固定连接字符串里的 charset=utf8mb4，再验证 SHOW VARIABLES 三值是否全为 utf8mb4。连接层不对，后面所有操作都是徒劳。
