为什么加了索引查询还是慢？理解 MySQL 索引失效的常见原因与优化思路

在日常开发中，经常会遇到这样的困惑：表上明明已经建了索引，查询却依然很慢。于是有人继续加索引，有人怀疑是数据库本身的问题。其实很多时候，问题不在于索引不存在，而在于查询的写法让优化器无法使用索引，或者索引的设计与查询模式并不匹配。本文梳理几种常见的索引失效场景，以及一套相对稳妥的排查与优化思路。

一、先理解索引能做什么，不能做什么

以常见的 B-Tree 索引为例，它本质上是一种有序的数据结构，能够帮助数据库快速定位到满足条件的记录范围，避免逐行扫描整张表。但索引只对“可以按顺序查找”的条件友好。如果查询条件无法转化为有效的范围定位，数据库就只能退化为扫描更多数据，或者放弃使用该索引。

另外，索引本身也有成本：写入时需要维护，占用额外存储空间，过多或不合理的索引反而会拖慢写入并增加优化器选择的难度。因此，优化的目标不是索引越多越好，而是让常用的查询能够稳定地命中合适的索引。

二、常见的索引失效写法

1. 对索引列做函数运算或算术运算

例如对日期列使用函数转换后再比较，或者对数值列做加减运算。经过运算之后，数据库很难直接利用索引的有序性，往往只能对每一行计算后再比较。更稳妥的做法，是把运算移到常量一侧，让索引列保持“干净”的比较形式。

2. 发生隐式类型转换

当列类型与查询传入的值类型不一致时，数据库可能进行隐式转换。典型的例子是字符类型的列用数值比较，或者数值列用字符串比较。类型不一致不仅可能改变比较语义，还可能导致索引无法正常使用。保持应用层参数类型与表结构一致，是一个容易被忽视但很有效的习惯。

3. LIKE 以通配符开头

以百分号开头的模糊匹配，相当于没有给出明确的起始范围，索引的有序查找也就无从下手。如果业务确实需要前缀匹配，可以保留前缀部分；如果需要全文检索，则应考虑更合适的全文检索方案，而不是强行依赖普通索引。

4. 复合索引没有遵循最左前缀原则

复合索引的列是有顺序的。查询条件如果跳过了最左边的列，后续列的索引能力往往会大打折扣。设计复合索引时，应当把区分度高、查询中最常作为等值条件的列放在前面，同时结合实际查询语句的组合方式来验证，而不是凭感觉排列。

5. OR 条件与范围条件使用不当

当 OR 两侧的条件并不都具备索引支持时，优化器可能放弃索引。同样，复合索引中某个列使用了范围条件之后，后续列的索引效果也可能受限。遇到这类语句时，可以先拆分逻辑，确认每一条分支是否都能走索引，再决定是否改写为 UNION 或者调整索引结构。

三、动手之前，先看执行计划

在猜测之前，先用 EXPLAIN 查看执行计划，关注访问类型、可能用到的索引、实际选择的索引以及预估扫描行数。例如：

EXPLAIN SELECT id, name FROM users WHERE status = 1 AND created_at >= '2026-01-01' ORDER BY created_at LIMIT 20;

执行计划只是优化器的估算，不是最终结论，但它能快速告诉我们：查询是否走了索引、是否需要额外排序或回表、扫描范围是否合理。把“感觉慢”变成“哪一步扫描了过多数据”，后续优化才有方向。

四、优化时可以优先考虑的思路

第一，改写查询，让条件更贴近索引结构，例如避免对索引列运算、统一类型、补齐最左列条件。第二，调整索引设计，例如为高频查询建立覆盖索引，让查询可以直接从索引中取到所需列，减少回表。第三，控制返回的数据量，例如只取需要的列、合理分页，避免 SELECT * 把大量不需要的字段也拖入结果集。

需要注意的是，覆盖索引和复合索引并非万能。索引列越多，写入和维护成本越高，收益也需要结合实际查询频率来判断。建议每次只做一处改动，然后重新查看执行计划和实际表现，避免同时改多处导致无法定位真正起作用的因素。

五、一个可落地的自查清单

• 查询条件中的索引列是否被函数、运算或隐式转换破坏？
• 复合索引的顺序是否与高频查询条件一致？
• 是否只取了必要的列，是否避免了不必要的大范围扫描？
• 执行计划是否显示走了预期索引，是否出现了额外的排序或临时表？
• 索引改动后，写入和常用查询是否都得到了验证？

索引优化没有一劳永逸的答案，表的数据分布、查询模式和业务变化都会影响最优选择。养成“先看执行计划、再改写查询、最后调整索引”的习惯，比盲目加索引更能长期保持查询稳定。希望这份梳理，能帮助你在下次遇到慢查询时，更快找到真正的原因。