根本原因是隐式转换破坏B+树索引依赖的列值原始有序性，导致MySQL无法安全使用索引；如WHERE varchar_col = 123会逐行CAST转换，使EXPLAIN显示type:ALL、key:NULL，且可能误匹配'101abc'→101.0等非预期结果。
隐式类型转换导致索引失效，根本原因不是 MySQL “不想用索引”，而是它**没法安全地用**——B+ 树索引依赖列值的原始有序性，而隐式转换相当于在索引列上动态套了一个 CAST 或 CONVERT，破坏了这个前提。
WHERE varchar_col = 123 触发全表扫描
当 varchar_col 是字符串类型，但查询写成 WHERE varchar_col = 123（不加引号），MySQL 必须对每一行的 varchar_col 值执行类似 CAST(varchar_col AS SIGNED) 的转换，再跟整数 123 比较。
- 这个转换无法下推到索引遍历层，B+ 树无法跳过分支，只能逐行取值、转数字、比大小
-
EXPLAIN中会看到type: ALL、key: NULL，哪怕表只有 10 行，逻辑上也是全表扫 - 像
'101abc'→101.0、'abc'→0.0这类非预期转换还会导致查出错误结果
WHERE int_col = '123' 多数情况仍走索引，但有陷阱
反向操作（int 列 vs 字符串字面量）通常能走索引，因为 MySQL 把 '123' 转成整数发生在优化器阶段，不污染索引列本身。
- 前提是字符串可无损转为整数：
'123'、' 123 '（自动 trim）都 OK - 但
'123abc'会被截断为123，'99999999999999999999'可能溢出变0或最大整数，查不到数据却仍显示key有值 - 用
EXPLAIN FORMAT=TRADITIONAL看key_len和rows：若rows接近总行数，说明实际效率已崩
联合索引中最左列一隐式转换，整个前缀失效
比如联合索引 KEY idx_code_age_name (code, age, name)，其中 code 是 VARCHAR，但写了 WHERE code = 101 AND age = 21：
-
code = 101触发隐式转换 → 最左前缀失效 → 整个联合索引退化 -
age = 21无法利用索引下推，除非age单独建了索引 - ORM 场景更危险：Java 传
Integer给VARCHAR字段，JDBC 不报错，SQL 执行时已悄悄转换
别信“MySQL 8.0 默认禁用了隐式转换”
MySQL 8.0 并未改变默认行为。官方文档明确说明：类型转换规则与 5.7 基本一致，优先级仍是「数字 > 日期 > 字符串」。
-
sql_mode中的STRICT_TRANS_TABLES不影响隐式转换是否发生，只控制出错时是警告还是报错 - 真正有效的防护是应用层强校验：所有传给
VARCHAR字段的值必须是字符串；所有拼接 SQL 的地方（如 MyBatis${}）必须确保引号存在 - 慢查询日志里抓出真实执行的 SQL，用
EXPLAIN对照看key_len和ref，比猜更可靠
最常被忽略的一点：问题往往不出现在建表或写 SQL 的那一刻，而出现在参数来源——前端传参是字符串，后端没做类型检查就直塞 PreparedStatement；或者运维脚本硬编码 status = '1'，而数据库里 status 是 TINYINT。这类问题不报错，但数据量一上来，CPU 和 IO 就突然拉满。
