日期：2026-07-11
难度：中等
标签：#面试 #MySQL #索引 #SQL优化 #VIP
一句话答案
小表、高频写且低频查询、低选择性字段、频繁更新的大字段、无法匹配真实查询模式或与现有索引重复时，不应盲目建立索引。
面试口语版
索引不是免费的。每个二级索引都会占空间，INSERT、DELETE 和索引列 UPDATE 都要维护 B+ 树，还可能增加页分裂、redo 和 binlog。数据量很小、查询本来就需要返回大部分行，或者性别、状态等低选择性字段单独查询时，全表扫描可能更划算。很长的文本、频繁变化的列也不适合随意建完整索引。最终应从慢 SQL 和查询模式出发，用联合索引覆盖高频条件，检查是否与现有索引重复，并在上线后观察真实使用率。
原理拆解
| 不推荐场景 | 原因 | 可能替代方案 |
|---|---|---|
| 小表或高比例返回 | 全表扫描成本低 | 不建或等待增长 |
| 高写低读 | 维护成本大于查询收益 | 缓存、异步查询 |
| 单独低选择性列 | 过滤能力弱 | 与高选择性条件建联合索引 |
| 超长文本 | 索引大、维护贵 | 前缀索引、全文检索 |
| 重复/被包含索引 | 空间与写放大 | 合并或删除冗余索引 |
关键细节
- 低选择性列并非永远不能建索引，若查询只取极少数稀有值或能形成覆盖索引，仍可能有效。
- 主键、唯一约束和外键相关索引还承担正确性或约束功能，不能只看查询次数。
- 是否使用索引由优化器按成本决定，有索引不等于一定走索引。
面试官追问
- 性别字段一定不能建索引吗？
- 如何识别重复索引？
- 为什么索引会降低写性能？
高分补充
索引治理应记录创建原因、目标 SQL 和收益指标，并定期审计未使用和重复索引。
学习清单
- 从选择性、读写比、字段宽度、重复性四点判断。
维护与整理 · Yihui在 GitHub 上编辑