MySQL索引失效的五大主因：①WHERE中对索引列使用函数或表达式；②联合索引未遵循最左前缀原则；③隐式类型转换；④LIKE左模糊、OR、IS NULL等特定写法；⑤!=、NOT IN等高排除率操作导致优化器弃用索引。
WHERE 中用了函数或表达式，索引直接失效
MySQL 索引里存的是原始值，一旦你在 WHERE 条件里对索引列做计算、取子串、格式化时间，优化器就无法用索引做快速定位。
常见错误现象：EXPLAIN 显示 type=ALL 或 key=NULL，哪怕字段明明建了索引。
-
WHERE DATE(create_time) = '2024-04-21'→ 改成WHERE create_time >= '2024-04-21' AND create_time -
WHERE SUBSTRING(name, 1, 3) = 'Tom'→ 改成WHERE name LIKE 'Tom%' -
WHERE price * 1.1 > 100→ 改成WHERE price > 100 / 1.1
注意：MySQL 5.7+ 可用「生成列 + 索引」绕过这类限制，但要权衡写入开销和维护成本。
联合索引没按最左前缀用，右边全作废
复合索引 INDEX(a, b, c) 不是“三个字段都有索引”，而是按顺序组织的 B+ 树。跳过最左或中间列，后续列就进不了搜索路径。
使用场景：查用户时经常按 city 和 age 过滤，但只建了 INDEX(city, age)，却写了 WHERE age > 25 —— 这条语句根本不会走索引。
- ❌
WHERE b = 2 AND c = 3（没包含a） - ❌
WHERE a = 1 AND c = 3（跳过了b） - ✅
WHERE a = 1 AND b > 10 AND c = 3（c不生效，但a,b有效）
别指望优化器“聪明地重排条件顺序”——它只认定义顺序。业务查询模式变了，索引也得跟着调。
隐式类型转换让索引悄悄下线
字段是 VARCHAR，你传数字；字段是 INT，你传字符串。MySQL 会自动加转换函数，等价于在索引列上套了一层函数，索引立刻失效。
典型错误：
-
SELECT * FROM users WHERE id = '123'（id是INT） -
SELECT * FROM orders WHERE order_no = 10001（order_no是VARCHAR） -
JOIN时两边字段类型不一致，比如t1.user_id INT关联t2.uid VARCHAR
解决方法很简单：查什么类型，就传什么类型。用 EXPLAIN 看 Extra 字段，如果出现 Using where; Using index 是好的，但若带 Using temporary 或没显示 key，就要怀疑类型是否对齐。
LIKE 左模糊、OR 拆分、IS NULL 都容易踩坑
这些不是“绝对不走索引”，而是在多数数据分布和 MySQL 版本下，优化器倾向放弃索引走全表扫描。
-
LIKE '%abc'：B+ 树没法从中间开始找，必须扫全量 → 改用LIKE 'abc%'或上FULLTEXT -
WHERE a = 1 OR b = 2：即使a和b各有单列索引，OR通常也不走 → 拆成UNION或建INDEX(a,b) -
WHERE status IS NULL：如果字段没设NOT NULL，IS NULL查询基本不走索引 → 建索引前先加约束，或显式建INDEX(status)（MySQL 8.0+ 对IS NULL支持更好）
最容易被忽略的一点：索引列参与 !=、NOT IN、NOT EXISTS 时，只要排除比例稍高（比如 > 15%），优化器大概率放弃索引——这不是 bug，是成本估算的结果。
