JOIN字段类型不一致必然导致索引失效，MySQL会隐式转换整列（如VARCHAR转BIGINT），使EXPLAIN显示type=ALL、key=NULL；字符集或排序规则不一致同理，须用SHOW FULL COLUMNS核对Type/Collation，并通过ALTER TABLE MODIFY统一定义。
JOIN字段类型不一致，索引一定失效，不是“可能慢”
MySQL在执行ON a.id = b.user_id时，如果a.id是BIGINT而b.user_id是VARCHAR，它不会报错，而是悄悄把整列b.user_id转成数字再比对——这个转换过程让b表上的索引完全失效。EXPLAIN里type显示ALL、key为NULL，就是最直接证据。
PostgreSQL反而更诚实：直接报错operator does not exist: bigint = text，逼你立刻处理。MySQL的“宽容”恰恰是坑人的开始。
- 哪怕两列都是
VARCHAR，长度不同（如VARCHAR(20)vsVARCHAR(100)）也可能触发隐式转换 - 字符集或
COLLATION不一致（比如utf8mb4_general_civsutf8mb4_0900_as_cs）也会导致同样后果 - 外键约束字段同样适用这条规则——即使没写JOIN，建外键时也会做隐式比对，可能报
ERROR 1005
怎么快速定位是不是类型/字符集不一致导致的慢JOIN
别猜，用这两条命令直接看定义：
SHOW FULL COLUMNS FROM table_a LIKE 'id';SHOW FULL COLUMNS FROM table_b LIKE 'user_id';
重点核对三列：Type（是否同为BIGINT）、Collation（是否完全一致）、Extra（是否有auto_increment等干扰项）。
- 用
EXPLAIN FORMAT=TRADITIONAL跑原SQL，确认key列是否为空、rows是否异常高 - 如果
table_b有索引但key没显示出来，基本可以锁定是类型或COLLATION问题 - 注意：
CONVERT()或CAST()包裹字段后能“跑通”，但只是掩盖问题，索引依然不走
ALTER TABLE改字段类型时最容易踩的三个坑
想修，但一改就翻车。常见错误操作包括只改CHARACTER SET不改COLLATE、用CHANGE COLUMN却漏掉COLUMN_FORMAT、大表没加ALGORITHM=INPLACE。
正确姿势是：
ALTER TABLE table_b MODIFY user_id BIGINT UNSIGNED NOT NULL DEFAULT '0' COLLATE utf8mb4_0900_as_cs;
- 必须
MODIFY（不是CHANGE），且显式写出完整字段定义，避免默认值/约束被重置 -
COLLATE必须和关联表字段完全一致；只写CHARACTER SET utf8mb4而不指定COLLATE，MySQL会按库默认补，大概率不匹配 - 大表务必加
ALGORITHM=INPLACE, LOCK=NONE（需满足条件），否则锁表几小时不是夸张
应用层ORM不能帮你绕过类型不一致
MyBatis的#{userId}、JDBC的PreparedStatement只解决SQL注入和参数绑定，对字段定义层面的类型错配毫无作用。你传Long进去，数据库照样拿去跟VARCHAR字段比。
真正要管住的，是建表那一刻：
- 新表所有ID类字段统一用
BIGINT UNSIGNED，别用VARCHAR存数字 - 所有文本字段建表时显式声明：
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - Laravel迁移里写
$table->string('name')->collation('utf8mb4_0900_as_cs')，Django里配db_collation
等线上查出type=ALL再改，往往要停服、导数据、校验一致性——而建表时多敲10秒，能避开90%的关联性能坑。
