索引失效是因为隐式转换破坏b+树有序性：字符串字段用数字查询（如phone=138）、int字段用字符串条件（如id='123'）、join字段类型不一致，均触发隐式转换，导致全表扫描（explain显示type=all、key=null）。
因为隐式转换让MySQL无法在索引树上做快速定位，只能逐行计算转换后再比对——这直接破坏了B+树索引依赖的“有序性”和“列独立出现”原则。
WHERE里字符串和数字混用，为什么索引就没了？
MySQL优化器要求索引列必须“独立出现在WHERE条件中”，不能被任何函数或转换包裹。一旦字段类型和值类型不一致（比如user_code是VARCHAR，但写成WHERE user_code = 123456），MySQL就得对每一行的user_code值调用隐式转换函数（如CAST(user_code AS SIGNED)）来比对。这个过程等价于在索引列上做了函数操作，优化器判定无法下推索引查找。
-
EXPLAIN里看到type: ALL、key: NULL，基本就是它 - 哪怕只更新1行，
UPDATE也会锁住全表扫描范围内的所有行，引发并发阻塞 - 更隐蔽的是
IN (1,2,3)：只要列表里有一个值类型不对，整个IN就可能退化为全表扫
怎么验证是不是隐式转换惹的祸？
别信EXPLAIN UPDATE——MySQL 5.6.2之前根本不支持，5.6.2+又常因统计信息不准漏报。正确做法是用等价SELECT模拟：
- 把原
UPDATE的WHERE条件原样搬到SELECT *里，确保没加函数（例如别写WHERE DATE(create_time) = '2024-01-01'） - 重点看
type字段：const/ref表示走了索引，ALL就是全表扫 -
key为空≠没建索引，可能是联合索引最左前缀没满足（比如索引是(a,b,c)，但只写了WHERE b = 1）
ORM里最容易踩的坑在哪？
MyBatis的#{id}传参时，Java类型和数据库字段类型不匹配会悄悄触发隐式转换。例如Java用Long传给VARCHAR字段，或String传给BIGINT主键。
- MyBatis默认不做类型校验，生成的SQL可能是
WHERE id = '123'（id是BIGINT） - Spring Data JPA的
findByCode(123)如果code是VARCHAR，也会生成数字字面量 - 解决方案不是加
CONVERT()或CAST()——它们一样破坏索引；而是改Java参数类型或在Mapper里显式拼字符串
真正难防的不是写错引号，而是那些藏在框架封装下、日志里根本看不出类型差异的转换。查慢查询时，先盯死EXPLAIN SELECT的type和Extra，再翻表结构和实际传参类型，比猜更快。
