到这里，索引与查询优化这个阶段就讲完了。从第 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 占用。
- 高频核心查询：值得，优先保证它快。
- 低频偶发查询：可能不值得，容忍全表扫或用 limit 凑合。
- 没被使用的索引：纯负债，删掉。
代价观的核心是「不是越多越好，是越准越好」。一个精挑细选的复合索引，胜过十个拍脑袋建的单键索引。
设计观：查询形状决定索引形状
索引是为查询服务的，所以索引设计要从查询出发，而不是从字段出发。两个支柱：
- 类型选对：按查询形状（等值/范围/数组/地理/全文/过期/分片）对号入座。
- 顺序排对：复合索引按 ESR（等值→排序→范围）排字段，等值里再按选择性从高到低。
设计观的反面是「给每个字段都建索引」或「按字段在文档里的顺序建复合索引」——这两种都忽略了查询形状，建出来的索引要么用不上、要么只用一半。
验证观：explain 说了算，不靠感觉
索引设计完，必须用 explain 验证它是否真的被用上、用得有多充分。凭感觉判断「应该快了」是不够的，explain 会如实告诉你：走了哪个计划、扫了多少、回表了多少、慢在哪个 stage。
- 建索引后：跑
executionStats，看扫描比例是否健康。 - 改查询后：对比改前改后的
totalDocsExamined和耗时。 - 选计划存疑：用
allPlansExecution看候选对比。
验证观延伸到监控：慢查询监控要常态化，因为数据量增长和查询模式变化会让优化失效。这是一项持续工程，不是一次性任务。
这套地图怎么用
遇到查询性能问题，按这个顺序调用：
- 先看代价：这个查询值得优化吗？频率多高、影响多大？不值得就先放着。
- 再看设计：现有索引类型对吗？复合索引字段顺序符合 ESR 吗？
- 用 explain 验证：实际走的是什么计划？扫描比例健康吗？
- 按闭环修复：落到五条分支之一，对症动手。
- 改完再验证 + 监控：确认有效，纳入常态监控。
这五步背后就是三个判断轴在起作用：代价观决定「要不要做」，设计观决定「怎么做」，验证观决定「做得对不对」。
阶段衔接
索引与查询优化回答的是「查询怎么高效地用索引找到数据」。但还有一类性能问题它解决不了：数据本身比内存大时怎么办。索引再好，如果数据页不在 Cache 里，查询也要读盘，而读盘比读内存慢几个数量级。
这个问题要下沉到存储引擎层。下一阶段（13–17）会进入 WiredTiger 的内部：B-tree 怎么组织、Cache 怎么治理、journal 怎么保证持久化、压缩怎么省空间、工作集超过内存时怎么应对。那是「数据怎么在内存和磁盘之间流动」的世界，和这一阶段的「查询怎么用索引」是互补的两半。
理解了这两半，MongoDB 的性能主战场——查询和存储——就有了完整的地基。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MongoDB」，欢迎关注公众号 「十三Tech」。后续会进入存储引擎、复制集、分片集群和架构选型这条线。
