为什么MySQL中的隐式类型转换会导致DML语句无法命中索引？

隐式类型转换导致索引失效：字符串字段=数字字面量必然失效；数字字段=字符串字面量通常可用但有风险；datetime字段需标准格式；字符集不一致引发collation冲突；务必严格对齐字段与条件值类型。

WHERE 条件中发生隐式类型转换，索引列被函数包裹或重计算，优化器无法利用B+Tree的有序结构做快速定位，只能全表扫描。

WHERE 字符串字段 = 数字字面量 → 索引必然失效

这是最典型、最危险的场景。比如 mobile 是 VARCHAR 类型，建了索引，但写成：
SELECT * FROM users WHERE mobile = 13812345678;
MySQL 实际执行的是：CAST(mobile AS SIGNED) = 13812345678。
注意：被 CAST() 包裹的是索引列本身，B+Tree 的原始排序完全失效。
即使你只查一条，EXPLAIN 的 key 列也会是 NULL，type 变成 ALL。

• 字符串转数字时，多个不同字符串可能转成同一个数字（如 '123'、'123abc'、'0123' 都转成 123），索引无法保证“等值唯一映射”
• 字段定义为 VARCHAR 却传入无引号数字，ORM（如 MyBatis 动态 SQL）或拼接字符串时极易踩坑
• MySQL 8.0+ 的 SHOW WARNINGS 会明确提示：Warning 1739: Implicit type conversion

WHERE 数字字段 = 字符串字面量 → 索引通常仍可用，但有风险

例如 id 是 INT，写成：WHERE id = '123'。
此时 MySQL 把右边字符串转成整数，id 列本身没被函数处理，B+Tree 还能用。
但要注意：
— 若字符串含非数字字符（如 '123a'），MySQL 转换后变成 123，语义已错
— 若字段是 BIGINT，而字符串超长（如 '9223372036854775808'），可能溢出或截断
— EXPLAIN 看起来走了索引，但 rows 异常高，说明内部做了隐式转换+校验

datetime 字段比较字符串时，格式决定索引是否生效

created_at 是 DATETIME，写成：WHERE created_at = '2025-01-01' ✅
MySQL 能识别标准格式，隐式转为日期值，索引正常走。
但写成：WHERE created_at = '2025/01/01' ❌ 或 WHERE created_at = '2025-01-01 10' ❌
前者因分隔符不匹配，后者因格式不完整，都可能触发全表扫描或报错 Incorrect datetime value。
更隐蔽的是 WHERE created_at > '2025-01-01' —— 看似没问题，但如果字段实际存的是带毫秒的 2025-01-01 00:00:00.123，而字符串被截断为 2025-01-01 00:00:00，范围查询结果可能偏差

JOIN 或 WHERE 中字符集不一致 → 表面像类型转换，实为 collation 冲突

两张表关联，users.name 是 utf8mb4_unicode_ci，logs.user_name 是 latin1_swedish_ci，写：ON users.name = logs.user_name。
MySQL 不会报错，但会强制做字符集转换，等价于在任一列上加函数，索引直接失效。
EXPLAIN 里 key 为空，Extra 出现 Using where; Using join buffer 就是信号。
修复必须统一字符集和排序规则，不能只靠 CONVERT() 或 CASE 临时绕过

真正麻烦的不是“会不会失效”，而是“失效得不明显”：小数据量下 EXPLAIN 显示用了索引，rows 却接近全表；线上流量一上来，CPU 瞬间拉满。最稳妥的方式，永远让条件值类型和字段定义严格对齐——别信 MySQL 的“自动适配”。