JOIN字段字符集或COLLATION不一致会导致隐式转换，使索引失效，触发全表扫描（type: ALL）或Using join buffer，查询从毫秒级骤降至秒级甚至分钟级。
为什么JOIN字段字符集或COLLATION不一致会让查询变慢
MySQL在执行JOIN时，如果关联字段的字符集（CHARACTER SET）或校对规则（COLLATION）不一致，会触发隐式转换——哪怕两个字段都建了索引，优化器也会放弃使用索引，降级为全表扫描或Using join buffer。典型表现是：EXPLAIN里被驱动表的type变成ALL，key为空，哪怕表只有几万行，查询也可能从几十毫秒拖到几秒甚至分钟。
怎么快速确认是不是字符集/COLLATION惹的祸
别猜，直接查定义：
- 用
SHOW CREATE TABLE t1和SHOW CREATE TABLE t2对比关联字段那一行，重点看末尾的CHARACTER SET xxx COLLATE xxx - 或者更精准：用
SHOW FULL COLUMNS FROM t1 LIKE 'user_id'，检查Collation列值；注意utf8mb4_general_ci和utf8mb4_0900_as_cs虽同属utf8mb4字符集，但校对规则不兼容，照样报错或失效 - 常见坑组合：
utf8vsutf8mb4、utf8mb4_binvsutf8mb4_0900_ai_ci、老表utf8mb4_general_civs 新表默认的utf8mb4_0900_as_cs
ALTER TABLE MODIFY才是真解法，不是加COLLATE
在ON子句里硬写t1.name COLLATE utf8mb4_0900_as_cs = t2.name COLLATE utf8mb4_0900_as_cs看似能过语法，但实际大概率仍不走索引——因为MySQL优化器会在执行前做隐式推导，只要字段原始COLLATION不同，就可能拒绝该表达式；即使侥幸通过，加了COLLATE的字段无法命中索引。
正确做法是统一字段定义：
- 先确认目标
COLLATION，比如跟主表保持一致：utf8mb4_0900_as_cs - 执行
ALTER TABLE t2 MODIFY user_id VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs——必须同时指定CHARACTER SET和COLLATE，只改一个没用 - 改完立刻跑
SHOW CREATE TABLE t2确认字段定义已更新，别只信SHOW FULL COLUMNS - 再
EXPLAIN FORMAT=TREE原SQL，看key是否出现索引名、type是否回到ref或eq_ref
外键、UNION、全文索引字段也得同步处理
只改JOIN条件里的字段，其他地方照样崩。外键约束本身就会触发字符串比对，如果外键字段COLLATION不一致，建表或插入时就可能报ERROR 1005: Can't create table；UNION结果集要求所有列字符集完全一致，否则报Illegal mix of collations；全文索引字段若参与MATCH ... AGAINST，同样受COLLATION影响。
真正容易被忽略的是：这些字段往往不在日常JOIN语句里显式出现，但数据库内部逻辑仍会做隐式比较——所以排查时得把所有关联、约束、合并场景涉及的字符串字段一并拉出来核对。
