索引有什么优缺点,项目中为何创建这些索引?
未标记
考查重点:查询收益与写入维护成本。索引减少扫描并支持有序访问,代价是空间与写维护;按项目实际过滤、连接和排序设计列顺序,用执行计划与代表性数据验证
本题目录
参考答案
本答案基于相关资料,由 AI 辅助编写,供学习与面试准备参考。如有疏漏,欢迎反馈指正。
核心回答
索引以额外的数据结构换取更少的扫描,可加快过滤、连接及部分排序分组,也可用唯一索引约束重复数据。代价是占用空间和缓存,插入、删除及相关字段更新时还要维护索引,增加写入与建索引成本。
项目中应该围绕高频且重要的实际查询设计索引:先看过滤条件、排序、返回列和数据分布,再确定列顺序,用执行计划与代表性数据验证收益。索引不是越多越好,优化器也可能判断全表扫描更便宜。
怎样说明一个索引为什么存在
例如聊天列表经常按会话查最近消息,可以考虑以会话ID作为等值过滤前缀,再安排创建时间和消息ID以支持稳定排序。消息ID用于同一时间戳下确定顺序,避免分页遗漏或重复。这个例子解释的是查询模式与索引的对应关系,并不预设每个项目都有同一张表。
若读取列都能从索引取得,可以减少回表;但把大文本全部塞进索引通常会增大空间和维护成本。联合索引列顺序需同时考虑等值过滤、范围和排序,选择性只是因素之一,不能机械按“区分度最高列永远最前”决定。
怎样验证取舍
先用EXPLAIN看选择的索引、访问方式、估算行数与额外排序;允许实际执行时,再用EXPLAIN ANALYZE核对真实行数、循环和耗时。对比时保持数据量、数据分布与并发相近,并检查写入延迟、索引大小和冗余索引。
追问
- 低区分度字段一定不建索引吗? 不一定。与其他条件组合、覆盖读取或只查少数特殊值时仍可能有收益,应看实际成本。
- 为何建了不用? 可能查询返回比例很高、表很小、条件不匹配索引顺序、存在类型转换,或统计估算不同;先检查计划再定位原因。
- 唯一索引只为性能吗? 它还承担数据约束,例如业务请求号防重,不能只按查询次数判断是否删除。
参考资料
- 国内:JavaGuide / Snailclimb:MySQL 索引详解:参考索引减少扫描与写放大、空间成本的比较,解释正文中创建索引的收益与维护代价。
- 国内:JavaGuide / Snailclimb:MySQL 执行计划分析:执行计划的估算与实际行数、耗时说明如何验证索引是否服务目标查询。
- 国内:听风 / JavaGuide收录:MySQL 高性能优化规范建议:借鉴索引维护和冗余索引的讨论,说明正文中如何评估写入延迟、索引大小与冗余;未把文中数量建议当作通用阈值。
- 国外:MySQL / Oracle:How MySQL Uses Indexes:官方列出的索引用途说明为何索引是否有效取决于具体访问方式和成本。
- 国外:MySQL / Oracle:Multiple-Column Indexes:联合索引示例解释复合查询为什么要考虑列顺序,而不是给每列各建一个索引。

