图解 MongoDB 12｜索引与查询优化地图：一条主线，三个判断轴

到这里，索引与查询优化这个阶段就讲完了。从第 04 篇的索引模型，到第 11 篇的慢查询排查闭环，中间穿过了索引类型、ESR 原则、explain、覆盖查询。这些不是孤立的知识点，而是一条连贯的主线——每一步都在回答「怎么让查询又快又省」。

这一篇是阶段的收束，不引入新机制，而是把前面讲过的东西收成一张地图和三个判断轴，方便你在实际工作中快速调用。后面进入存储引擎与内存阶段（13–17）时，会从「查询怎么用索引」下沉到「索引和数据怎么在内存里」。

一条主线

这条主线有六个节点，对应这个阶段的六篇内容，按因果顺序排列：

04 索引模型：索引是 WiredTiger 里独立的 B-tree，是「查询加速 ÷ 写入与存储」的交易。这一篇建立了索引的成本观——加索引不是免费的。

07 索引类型：七种索引对应七种访问形状。选错类型等于建了用不上的 B-tree，是存储和写入的纯负债。

08 ESR 原则：复合索引的字段顺序是「等值 → 排序 → 范围」。这个顺序由 B-tree 的前缀有序性质决定，不是经验之谈，是物理规律。

09 explain：三层读执行计划，executionStats 给出真实代价。1:1:1 的扫描比例是健康的基准线。

10 覆盖查询：让索引里就有全部字段，totalDocsExamined = 0。这是查询优化的理想终点，但要权衡索引膨胀。

11 慢查询闭环：发现 → 定位 → 修复 → 验证 → 监控。五条修复分支覆盖了绝大多数慢查询场景。

把六个节点再抽象一层，得到三个贯穿始终的判断轴。实际做索引优化时，每个决策都落在这三个轴上：

索引用查询加速换写入和存储成本。每加一个索引，都要问：这个查询值不值得多养一棵 B-tree。判断依据是查询频率 × 加速收益，对比写入放大 × 存储占用 × Cache 占用。

代价观的核心是「不是越多越好，是越准越好」。一个精挑细选的复合索引，胜过十个拍脑袋建的单键索引。

索引是为查询服务的，所以索引设计要从查询出发，而不是从字段出发。两个支柱：

设计观的反面是「给每个字段都建索引」或「按字段在文档里的顺序建复合索引」——这两种都忽略了查询形状，建出来的索引要么用不上、要么只用一半。

索引设计完，必须用 explain 验证它是否真的被用上、用得有多充分。凭感觉判断「应该快了」是不够的，explain 会如实告诉你：走了哪个计划、扫了多少、回表了多少、慢在哪个 stage。

验证观延伸到监控：慢查询监控要常态化，因为数据量增长和查询模式变化会让优化失效。这是一项持续工程，不是一次性任务。

遇到查询性能问题，按这个顺序调用：

这五步背后就是三个判断轴在起作用：代价观决定「要不要做」，设计观决定「怎么做」，验证观决定「做得对不对」。

索引与查询优化回答的是「查询怎么高效地用索引找到数据」。但还有一类性能问题它解决不了：数据本身比内存大时怎么办。索引再好，如果数据页不在 Cache 里，查询也要读盘，而读盘比读内存慢几个数量级。

这个问题要下沉到存储引擎层。下一阶段（13–17）会进入 WiredTiger 的内部：B-tree 怎么组织、Cache 怎么治理、journal 怎么保证持久化、压缩怎么省空间、工作集超过内存时怎么应对。那是「数据怎么在内存和磁盘之间流动」的世界，和这一阶段的「查询怎么用索引」是互补的两半。

理解了这两半，MongoDB 的性能主战场——查询和存储——就有了完整的地基。

关于十三Tech

All in AI Agent 方向的架构师，专注 AI 工程实践。

相信 AI 是程序员的最佳搭档，帮助每一位开发者驾驭 AI。

公众号搜索「十三Tech」

本文首发：rubyfun.cn/posts/%E5%9…

《图解 MongoDB 12｜索引与查询优化地图：一条主线，三个判断轴》是转载文章，点击查看原文。