MySQL 中使用索引一定有效吗？如何排查索引效果？

日期：2026-07-11
标签：#面试 #八股 #后端 #MySQL #索引 #场景题

一句话答案

索引不一定被使用，也不一定比全表扫描快；应通过真实参数、执行计划、实际行数、回表次数和运行指标验证效果。

面试口语版

优化器基于成本选择访问路径。查询返回大比例数据、索引选择性差、统计信息不准或 SQL 写法破坏可搜索性时，可能不走索引。排查先确认 SQL 与参数，再看 EXPLAIN ANALYZE 的 chosen index、估算/实际行数、loops、过滤比例和耗时；检查是否有隐式转换、函数、前导 %、联合索引最左匹配、范围和排序问题。必要时更新统计信息或做不可见索引实验，FORCE INDEX 只适合作为验证或临时止损。

关键细节

• “用了索引”不代表快，大量回表和随机 I/O 仍可能很慢。
• 覆盖索引可减少回表，但会增加索引体积和写成本。
• 数据分布倾斜时，同一 SQL 不同参数可能需要不同计划。
• 观察 Handler 计数、Rows_examined、Buffer Pool 命中和慢日志。

面试官追问

1. 哪些写法容易导致索引失效？
2. FORCE INDEX 应该长期使用吗？
3. 如何判断索引选择性？

面试官追问参考答案

1. 哪些写法容易导致索引失效？

常见有索引列被函数或计算包裹、字符串与数字隐式转换、LIKE 前导通配符、联合索引未满足可用前缀，以及条件返回比例过大。是否失效仍应以具体版本执行计划为准。

2. FORCE INDEX 应该长期使用吗？

通常不建议，它会把当前数据分布下的判断固化，数据增长或版本升级后可能更差。应优先修复统计信息、索引和 SQL；紧急止损使用后也要监控并安排移除评估。

3. 如何判断索引选择性？

选择性可近似为不同值数量除以总行数，但平均值会掩盖数据倾斜。应查看直方图、常见值分布和目标查询的实际过滤比例，再结合回表成本判断。

学习清单

• 理解成本模型而非背“索引失效口诀”。
• 能用执行计划验证索引收益。