在数据库使用中，我们经常会遇到一种情况：明明在相关字段上建立了索引，但执行SQL时数据库却没有走索引，而是进行了全表扫描，导致查询性能下降。要理解这个问题，需要先了解数据库优化器的工作方式。优化器会基于表的统计信息、数据分布以及查询条件来估算不同执行路径的成本，并选择它认为成本最低的方式。当某些条件让索引的查询成本高于全表扫描时，优化器就会放弃使用索引。
常见不走索引的原因
1. 对索引列使用函数或运算
如果在WHERE条件中对索引列使用了函数或者进行了算术运算，数据库通常无法直接使用该列上的B树索引。例如下面的SQL：
-- 对索引列使用函数，导致索引失效 SELECT * FROM user WHERE DATE(create_time) = '2023-01-01'; -- 改写为范围查询，可以使用索引 SELECT * FROM user WHERE create_time >= '2023-01-01' AND create_time < '2023-01-02';
2. 隐式类型转换
当查询条件中的值与索引列类型不一致时，数据库可能进行隐式转换，这也会让索引失效。比如索引列是字符串类型，但传入了数字：
-- phone是varchar类型且有索引，传入数字会引发隐式转换 SELECT * FROM user WHERE phone = 13800000000; -- 正确写法，使用字符串字面量 SELECT * FROM user WHERE phone = '13800000000';
3. 模糊查询以通配符开头
使用 LIKE 时，如果通配符在开头，例如 LIKE '%abc'，B树索引无法从前面匹配，因此不会走索引。只有 LIKE 'abc%' 这种前缀匹配才能利用索引。
4. 索引选择性差或回表代价高
如果某个字段的取值非常集中，比如性别字段只有男和女，优化器会认为使用索引后再回表查询的成本比直接全表扫描更高，从而放弃索引。此外，当查询需要返回表中大部分数据时，全表扫描往往更快。
如何通过执行计划确认
在MySQL中可以使用 EXPLAIN 来查看SQL的执行计划，重点关注 type 和 key 字段：
EXPLAIN SELECT * FROM user WHERE phone = '13800000000';
如果 key 为NULL，说明没有使用索引；如果是 ALL，表示进行了全表扫描。
优化建议
- 避免在索引列上使用函数、运算或隐式转换
- 模糊查询尽量使用前缀匹配
- 对选择性高的列建立索引，必要时使用联合索引覆盖查询
- 定期更新统计信息，让优化器做出准确判断
理解优化器的决策逻辑，结合执行计划分析，才能写出稳定命中索引的SQL语句。