这是「图解 MongoDB」系列的最后一篇。36 讲，从文档模型的本质，一路讲到存储引擎、复制集、分片集群、运维和架构。这一篇不引入新内容，而是把整个系列收束成一张地图和一个选型判断——读完这 36 篇，你应该能回答一个根本问题：什么场景该用 MongoDB，什么场景不该用。
六个阶段，一条主线
整个系列围绕一条主线展开：理解 MongoDB 的能力边界，在边界内把它用好。六个阶段依次回答了六个问题：
阶段一（01–06）文档模型：MongoDB 是什么？为什么是文档数据库？BSON、CRUD 链路、建模、模式演进、事务。这一阶段建立了「文档模型的本质和访问局部性」的认知。
阶段二（07–12）索引与查询：怎么让查询又快又省？索引类型、ESR 原则、explain、覆盖查询、慢查询闭环。这一阶段建立了「查询优化 = 代价观 + 设计观 + 验证观」的方法论。
阶段三（13–17）存储引擎与内存：性能的地基在哪？WiredTiger、Cache 淘汰、journal、压缩、工作集。这一阶段下沉到「数据怎么在内存和磁盘间流动」，解释了性能抖动的根因。
阶段四（18–23）复制与高可用：单点故障怎么解决？复制集拓扑、oplog、复制延迟、选举、读写关注、两地三中心。这一阶段建立了「数据冗余 + 自动 failover」的高可用能力。
阶段五（24–30）分片集群：单机装不下怎么办？分片架构、片键设计、范围/哈希、balancer、陷阱、查询路由。这一阶段建立了「水平扩展」的容量能力，以及「片键是命运决定点」的核心认知。
阶段六（31–36）运维与架构：怎么让系统稳定运行？备份恢复、Change Stream、监控、安全、数据中台、选型。这一阶段把前面所有机制落到运维实践和架构选型。
一条贯穿的主线：理解边界
如果从 36 篇里提炼一个核心认知，那就是理解边界：
- 文档模型擅长「整体读写」，不擅长「强关联」。
- 索引让查询快，代价是写入和存储——每个索引都要值回成本。
- 内存是性能的分水岭——工作集超内存就是容量拐点。
- 复制集解决高可用，分片解决容量——不要混淆，能不用分片就不用。
- 片键一旦选定极难改——上线前仔细设计。
- MongoDB 是灵活的业务主库，不是万能库——用对场景才强大。
这些边界认知，比记住某个命令或参数更重要。机制会随版本演进，但「理解边界、在边界内做判断」的能力是长期的。
该不该选 MongoDB
把整个系列收束成一个选型判断。
适合用 MongoDB 的场景：
- 数据「整体读整体写」、结构灵活会演进——内容管理、配置、用户画像、订单详情、商品目录。
- 高并发 OLTP、需要水平扩展、访问模式以单文档为主。
- 地理空间（LBS）、时序数据（IoT、监控）、有专门集合类型支持的场景。
- 业务快速迭代、字段频繁变更、不想被 schema 锁死。
不适合用 MongoDB 的场景：
- 强关联、重度 JOIN、强多表事务——ERP/财务核心这类，关系库（MySQL/PostgreSQL）更合适。
- 重度分析——交给数仓（ClickHouse、StarRocks）。
- 极低延迟（亚毫秒）——交给 Redis。
- 复杂全文搜索——交给 Elasticsearch。
核心判断点是数据访问模式：整体读写、灵活结构 → MongoDB；强关联、强事务 → 关系库；分析 → 数仓。现实中很多系统是多库协作，MongoDB 做灵活的业务主库，关系库做强事务的账务，Redis 做缓存，ES 做搜索，数仓做分析。不要试图用一个数据库解决所有问题。
写在最后
这套「图解 MongoDB」的定位，不是 MongoDB 命令手册，而是从架构师视角拆解它的机制、边界和取舍。每篇都试图回答「这个机制为什么这么设计、它解决什么问题、代价是什么」，而不是罗列知识点。
如果这 36 篇能帮你建立起对 MongoDB 的「判断坐标」——知道它能做什么、不能做什么、什么时候该用它、用它时要注意什么——那这套系列的目的就达到了。
技术会演进，MongoDB 也在持续迭代（多文档事务、分片事务、时间序列、列压缩、可查询加密……）。但底层的判断框架——文档模型的访问局部性、索引的代价观、内存的容量拐点、复制的多数派、分片的片键命运——是相对稳定的。掌握了这些，面对任何新版本、新特性，你都能快速判断它的价值边界。
感谢跟完这套系列。如果对其中某个主题想深入，欢迎在公众号交流。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
「图解 MongoDB」36 讲到这里就完结了。如果你觉得有收获，欢迎关注公众号 「十三Tech」，后续会继续输出后端架构、AI 工程和系统设计的图解内容。
