为什么你的MySQL SQL语句突然不走索引了？常见原因与排查方法

在MySQL日常查询中，有时表上明明创建了合适的索引，但执行同一条SQL时优化器却选择了全表扫描，导致响应时间从毫秒级退化到秒级甚至更久。理解优化器放弃索引的底层逻辑，是写出高性能SQL的关键。

一、对索引列使用函数或表达式

最常见的一种索引失效场景，是在WHERE条件中直接对索引字段调用函数，或者让索引列参与算术运算。B+树索引保存的是列的原始值，一旦列值被函数处理，优化器就无法直接利用树结构定位，只能逐行计算后再过滤。

例如用户表users在create_time字段建有索引，但下面这条语句就不会走索引：

-- 错误写法：对索引列使用DATE函数
SELECT * FROM users WHERE DATE(create_time) = '2023-08-01';

-- 正确写法：使用范围查询
SELECT * FROM users WHERE create_time >= '2023-08-01 00:00:00'
  AND create_time < '2023-08-02 00:00:00';

改写后，优化器能利用索引的有序性快速圈定时间区间，避免全表扫描。类似的还有UPPER(name)、age + 1 = 20等写法，都应尽量把运算放到等号右侧常量上。

二、隐式类型转换导致索引失效

当SQL中传入的值类型与列定义类型不一致时，MySQL会尝试做隐式转换。如果转换发生在索引列一侧，索引同样会失效。这种问题在字符串与数字混用时尤其隐蔽。

假设phone字段是varchar类型且建有索引，以下语句将不会走索引：

-- phone是varchar，但传入数字，触发隐式转换
SELECT * FROM users WHERE phone = 13800000000;

-- 正确写法：传入字符串
SELECT * FROM users WHERE phone = '13800000000';

使用EXPLAIN可以看到，错误写法中key列为NULL，而正确写法能命中phone索引。因此在拼接SQL或书写参数时，务必保证传入类型与表结构一致。

三、模糊查询与最左前缀破坏

对于联合索引，MySQL遵循最左前缀原则。如果查询条件没有从索引第一列开始，或者like以通配符开头，都会导致索引无法有效使用。

以联合索引(name, age)为例，下面两种情况容易出问题：

-- 左模糊，索引失效
SELECT * FROM users WHERE name LIKE '%明';

-- 跳过最左列，只用age，联合索引失效
SELECT * FROM users WHERE age = 20;

如果业务必须使用左模糊，可考虑使用全文索引或倒排索引方案；对于联合索引，应尽量把过滤性强的列放在前面，并保证查询条件覆盖最左列。

四、范围查询后的索引列断裂

在联合索引中，如果某一列使用了范围查询（如>、<、BETWEEN），那么它后面的索引列将无法正常用于过滤，只能作为排序或覆盖扫描的辅助。

例如索引为(a, b, c)，执行如下语句：

SELECT * FROM t WHERE a = 1 AND b > 10 AND c = 2;

此时索引只能用到(a, b)两列，c上的条件是在回表后判断的。若频繁按此模式查询，可调整索引顺序为(a, c, b)，让等值条件靠前，范围条件靠后。

五、使用EXPLAIN排查索引使用情况

遇到疑似不走索引的SQL，第一步应当用EXPLAIN查看执行计划。重点关注type列与key列：type为ALL表示全表扫描，key为NULL表示未用索引。

EXPLAIN SELECT * FROM users WHERE DATE(create_time) = '2023-08-01';

输出中若看到Extra出现Using where且key为空，就说明优化器放弃了索引。结合上述场景逐一比对SQL写法，通常能快速定位问题并改写解决。

掌握这些典型模式后，在编写或审查SQL时就能主动规避索引失效，保障数据库查询稳定高效。

MySQL索引失效SQL优化修改时间：2026-08-01 02:18:23