join关联失败主因是字段字符集不一致，需用convert()在on子句中统一编码，避免where转换阻塞索引；长期应alter table统一字符集与校对规则。
JOIN前字段编码不一致导致关联失败
MySQL里用JOIN连两个表，结果返回空——不是逻辑错，是字段值看着一样却匹配不上。常见于一个表用utf8mb4存中文，另一个是latin1或gbk，哪怕都显示“张三”，底层字节完全不同，=直接失效。
- 先用
SHOW CREATE TABLE 表名确认两边字段的CHARACTER SET和COLLATION - 别依赖客户端自动转码，
SET NAMES只影响连接层，不改变字段存储编码 - 如果只是临时查，用
CONVERT()或CAST()在ON子句里强制对齐，比如ON t1.name = CONVERT(t2.name USING utf8mb4) - 注意
CONVERT(... USING ...)失败时会转成?，可能静默丢数据；加COLLATE utf8mb4_unicode_ci可避免大小写/重音匹配问题
CONVERT()和CAST()在ON条件里怎么选
CONVERT()更直观，支持USING语法；CAST()标准SQL兼容性好，但MySQL里不支持直接指定字符集，得套一层CONVERT(CAST(...) USING ...)才管用。
- 优先用
CONVERT(col USING utf8mb4)，语义清楚，出错也容易定位 - 如果字段本身是
BLOB或TEXT无明确字符集，CONVERT()能兜底，CAST()可能报Illegal mix of collations - 别在
WHERE里转换被JOIN的字段——会阻止索引使用；必须在ON里做，且只转驱动表以外的那一侧 - 示例：
LEFT JOIN t2 ON t1.code = CONVERT(t2.code USING utf8mb4)，假设t1是驱动表，t2.code编码旧
JOIN后ORDER BY中文乱序或报错
关联完一排序，中文变成乱码或者报Illegal mix of collations，本质还是字符集没对齐，ORDER BY字段参与了隐式转换。
- 确保
SELECT列表里所有用于排序的字段，字符集和校对规则一致，可用COLLATE utf8mb4_unicode_ci显式声明 - 如果
ORDER BY的是CONVERT()后的别名，MySQL可能无法下推排序，性能掉得明显 - 更稳的办法：在
JOIN前，用子查询把需要排序的字段提前转好，比如(SELECT id, CONVERT(name USING utf8mb4) AS name FROM t2) AS t2_fixed - 避免用
ORDER BY CONVERT(...)，函数调用会让排序走文件排序（Using filesort）
长期方案：别靠运行时转换硬扛
每次JOIN都加CONVERT()，代码难读、执行计划不可控、排查慢查询时容易漏看这层转换。
- 真正要动的是表结构：
ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 注意
CONVERT TO会锁表，大表务必在低峰期操作；若不能停服，用pt-online-schema-change分批改 - 改完立刻验证：查
INFORMATION_SCHEMA.COLUMNS确认character_set_name和collation_name已更新 - 应用层连接参数也要同步，比如JDBC URL加上
useUnicode=true&characterEncoding=utf8mb4
最麻烦的不是转换本身，而是不同表之间校对规则（COLLATION）不一致——比如一个用utf8mb4_general_ci，另一个用utf8mb4_0900_as_cs，这时候光改字符集还不够，得统一校对规则。
