MySQL 索引失效的几种常见写法

索引建了但没走，是慢查询里最常见的原因。下面几种写法在业务代码里出现频率很高，而且都不会报错，只会在某天数据量上来之后突然变慢。

对索引列做函数运算

-- 走不了索引
select * from orders where date(created_at) = '2026-03-01';

-- 改成范围查询
select * from orders
where created_at >= '2026-03-01 00:00:00'
  and created_at <  '2026-03-02 00:00:00';

where 左边的列一旦被函数包住，索引就没法用来定位了。隐式类型转换同理：字符串列写成 where code = 123，MySQL 会把列转成数字再比较，索引直接失效。

前导通配符

like '%abc' 无法利用 B+ 树的顺序性，只能全表扫。如果确实要按后缀查，考虑把字段反转后另存一列，或者上全文索引。

联合索引的最左前缀

索引 (a, b, c) 只有在条件里带上 a 时才能用上后续列。where b = 1 and c = 2 用不上这个索引，where a = 1 and c = 2 只能用到 a。

OR 混用不同列

select * from t where a = 1 or b = 2;

a 和 b 各自有索引时，优化器可能选择全表扫。拆成两个查询再 union all，通常更快。

排序方向不一致

order by a asc, b desc 在 MySQL 8.0 之前无法用索引排序，会触发 filesort。要么统一方向，要么调整索引定义。

验证方法

改完别靠猜，直接看执行计划：

explain select ...;

重点看 type（出现 ALL 就是全表扫）、key（是否命中预期索引）、rows（预估扫描行数）和 Extra（有没有 Using filesort、Using temporary）。