MySQL隐式类型转换导致索引失效的核心原因是索引列被函数包裹，破坏B+Tree有序结构；如VARCHAR字段=数字字面量时phone列被CAST处理，使key为NULL、type为ALL，全表扫描；INT字段=字符串虽显示走索引但存在语义错误、溢出及性能隐患；联合索引最左列一转换则前缀失效；datetime格式不标准或模糊匹配用函数亦致失效。
MySQL在字段发生隐式类型转换时索引必然失效，核心原因只有一个：索引列被函数包裹，B+Tree无法利用原始有序结构做快速定位。
WHERE varchar字段 = 数字字面量 → 索引直接报废
这是最危险、最常见、也最容易被忽略的场景。比如phone是VARCHAR(11)且建了索引，但写成：
SELECT * FROM users WHERE phone = 13812345678;
MySQL实际执行的是：
WHERE CAST(phone AS SIGNED) = 13812345678
注意：被CAST()处理的是索引列本身，不是条件值。B+Tree里存的是字符串顺序（如'0138...'、'138...'、'999...'），而CAST后变成数字比较，彻底破坏排序前提。
-
EXPLAIN中key为NULL、type为ALL，哪怕只查1行也是全表扫 - 前端传参是数字、MyBatis用
${id}拼接、日志脚本硬编码不加引号，都可能触发 - 手机号带前导零（如'0138...'）会被转成138...，查不到数据还无报错
WHERE int字段 = 字符串字面量 → 看似可用，实则高危
比如id是INT，写成：
SELECT * FROM orders WHERE id = '123';
此时MySQL把右边字符串转成整数，id列本身没被函数处理，所以EXPLAIN仍显示走索引——但这只是表象。
- 若字符串含非数字字符（如
'123abc'），转成123，语义已错 - 若字符串超长（如
'9223372036854775808'），在BIGINT字段上会溢出或截断为0 -
rows异常高？说明内部做了大量无效转换+校验，CPU和IO开销陡增
联合索引中最左列一转换，整个前缀就作废
比如有联合索引KEY idx_code_age_name (code, age, name)，其中code是VARCHAR，但写成：
WHERE code = 101 AND age = 21
只要code = 101触发隐式转换，最左前缀就崩了，age和name再也无法享受索引下推（index condition pushdown）。
- 哪怕
age是INT、name是VARCHAR，只要code类型不对，整个联合索引退化为无效 - ORM传
Integer给VARCHAR字段时，JDBC驱动通常不报错，但SQL执行时已悄悄转换 - 用
SHOW WARNINGS（MySQL 8.0+）能捕获Warning 1739: Implicit type conversion
datetime字段格式不对，索引也可能静默失效
created_at是DATETIME，写成：
WHERE created_at = '2025/01/01'
分隔符不标准，MySQL无法识别为日期，可能触发全表扫描或报Incorrect datetime value；更隐蔽的是：
WHERE created_at > '2025-01-01'
这个看似没问题，但如果字段实际存的是带毫秒的'2025-01-01 00:00:00.123'，字符串被截断为'2025-01-01 00:00:00'，范围查询结果可能漏掉毫秒部分的数据。
- 必须用标准格式：
'2025-01-01'、'2025-01-01 10:20:30' - 模糊匹配别用
DATE(created_at)，改用范围查询：created_at >= '2025-01-01' AND created_at < '2025-01-02' - 时间字段建议统一用
STR_TO_DATE()显式转换，避免依赖隐式行为
真正难防的不是语法错误，而是那些“看起来能跑通、EXPLAIN看着像走了索引、线上跑了半年才暴雷”的情况——类型对齐必须在应用层就卡死，不能指望数据库兜底。
