mysql 5.7中join或where字段类型不一致必致索引失效，因隐式转换等价于对索引列使用cast函数，使b+树无法跳过比较；explain显示key为null、rows=全表行数即为此现象。
MySQL 5.7 中 JOIN 或 WHERE 条件里只要关联字段类型不一致，索引基本就废了——不是“可能失效”，而是大概率直接走 type: ALL 全表扫描。
为什么 VARCHAR 和 INT 关联时索引一定不生效
核心原因是 MySQL 5.7 不会把查询值（比如 123）转成字符串去比，而是把索引列（比如 user_id VARCHAR(20)）逐行做 CAST(user_id AS SIGNED) 隐式转换。这等价于对索引列用了函数，B+ 树索引完全无法跳过比较过程。
- 现象：EXPLAIN 显示
key为NULL，rows等于全表行数，Extra出现Using where但没用索引 - 典型错误写法：
SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.id = 1001，其中o.user_id是VARCHAR，u.id是INT - 注意：哪怕只有一边是字符串、另一边是数字，只要参与等值比较，就会触发隐式转换；反过来（数字字段查字符串值）也一样，只是转换方向不同
如何快速定位哪一列在“悄悄转换”
别猜，用 EXPLAIN FORMAT=TREE（MySQL 8.0+）不行，5.7 就老实用 EXPLAIN SELECT ... 模拟你的 JOIN 查询逻辑，重点看三处：
-
possible_keys是否列出你预期的索引名；如果为空，说明优化器压根没考虑它 -
key实际选了哪个索引；如果是NULL，基本就是类型或表达式问题 -
Extra字段里有没有Using where; Using join buffer这类提示——有就说明右表被反复扫描，左表驱动后根本没走索引下探
更直接的办法：把 JOIN 拆成两个单表查询，分别 EXPLAIN 对应的 WHERE 条件，看各自是否命中索引。只要有一个不中，关联时必然失效。
修复手段优先级排序（从高到低）
不是所有方案都适合线上环境，按落地成本和稳定性排：
-
改应用层参数类型：最彻底。比如 Java 里传参用
String.valueOf(userId)而不是userId（int 型），确保 SQL 中WHERE user_id = '1001'类型严格匹配 -
显式 CAST 查询值：临时救急可用，如
WHERE user_id = CAST(1001 AS CHAR)，但注意CAST在 5.7 是函数，不能用于索引列本身；只能作用于常量侧 -
加生成列 + 索引（MySQL 5.7 支持）：若字段必须保留原类型（如兼容旧系统），可新增生成列并建索引，例如
ALTER TABLE orders ADD user_id_int INT AS (CAST(user_id AS UNSIGNED)) STORED, ADD INDEX idx_user_id_int (user_id_int)，然后 JOIN 改用该列 -
避免跨类型 JOIN：如果两表本不该类型不一致，立刻修正表结构——
ALTER TABLE t2 MODIFY COLUMN t1_id INT，再补索引；别留着“先跑起来再说”的隐患
LEFT JOIN 场景下更要小心
MySQL 5.7 对 UPDATE ... LEFT JOIN 的驱动表选择毫无商量余地：左表永远是驱动表。如果左表字段类型不对，又没 WHERE 过滤，结果就是全表扫描左表，再对右表每行都做一次隐式转换+全表扫。
- 反例：
UPDATE logs l LEFT JOIN users u ON l.user_id = u.id SET l.status = 'done'，其中l.user_id是VARCHAR，u.id是INT - 后果：即使
logs有百万行，也会触发百万次右表全表扫描（或索引全扫），锁等待飙升 - 解法：要么统一类型，要么拆成两步——先查出匹配的
u.id列表（确保类型一致），再用IN批量更新
类型不匹配的问题藏得深，往往只在数据量上去之后才爆发；而一旦出现在 JOIN 条件里，优化器连挣扎都不会挣扎，直接放弃索引。检查 EXPLAIN 输出里的 key 和 rows，比调优其他任何地方都来得实在。
