关联字段类型不一致必然导致索引失效，MySQL会进行隐式类型转换（如将VARCHAR转为INT或统一字符集/COLLATION），使JOIN无法使用索引，EXPLAIN显示type=ALL、key=NULL；须统一字段类型、字符集与校对规则，并通过EXPLAIN验证。
关联字段类型不一致，索引必然失效，不是“可能慢”，而是“一定全表扫描”。
MySQL对INT列和字符串做JOIN时到底发生了什么
当user_id是INT类型，而另一张表的user_id字段却是VARCHAR，执行ON a.user_id = b.user_id时，MySQL必须统一两边类型才能比较。它默认把整列b.user_id转成数字——这意味着无法使用b表上的索引，只能逐行转换再比对。
- EXPLAIN里
type显示ALL或index，key为NULL，就是最直接证据 - PostgreSQL更严格：直接报错
operator does not exist: integer = text，反而更容易暴露问题 - 即使两列都是字符串，
VARCHAR(50)和VARCHAR(100)在某些MySQL版本中也会触发隐式转换，导致索引跳过
字符集/校对规则不一致也会触发隐式转换
哪怕两列都是VARCHAR且长度相同，只要字符集或COLLATION不同（比如一张表用utf8mb4_general_ci，另一张用utf8mb4_unicode_ci），MySQL在JOIN时就会悄悄做转换，同样放弃索引。
- 查字段定义：
SHOW FULL COLUMNS FROM table_name，重点看Collation列 - 建表时显式统一：
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 临时修复可用
CONVERT(b.name USING utf8mb4) COLLATE utf8mb4_unicode_ci，但只是补丁，不是方案
ORM和预处理语句也救不了类型不匹配
很多人以为用了MyBatis的#{userId}或JDBC的PreparedStatement就安全了，其实不然。
- MyBatis里
#{userId}没加jdbcType=INTEGER，且传入的是字符串，照样拼出WHERE user_id = '123' - PDO默认开启
PDO::ATTR_EMULATE_PREPARES=true时，参数根本没发给MySQL服务端做类型校验，PHP层就按字符串处理了 - JSON字段解析后值天然是字符串，
$.user_id取出来直接用于JOIN，99%会出问题
怎么快速验证和修复
别靠猜，用EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+）看真实执行路径。
- 先查两表字段类型：
DESCRIBE table_a和DESCRIBE table_b，对比Type和Collation - 强制走索引测试：
SELECT * FROM a JOIN b FORCE INDEX (idx_user_id) ON a.user_id = b.user_id，如果key仍为NULL，说明索引本身不可用 - 修复优先级：改表结构 > 改应用传参 > 加CAST兜底（如
ON a.user_id = CAST(b.user_id AS SIGNED)）
最容易被忽略的一点：跨库JOIN时，两个库的默认字符集可能不同，哪怕单表内字段类型一致，JOIN依然失效。这种问题在线上跑了一年都可能不暴露，直到某次数据量突增才爆发。
