mongodb

葫芦和十三

图解 MongoDB 19｜Oplog：复制的真正载体，不是文档是操作上一篇讲了复制集的拓扑：一个 Primary 写、多个 Secondary 备。但留了个关键问题没回答：Secondary 到底是怎么「拿到」Primary 的数据的。是 Primary 把每个文档推过去，还是 Secondary 主动拉？

葫芦和十三

图解 MongoDB 20｜复制延迟与 catch up：Secondary 为什么跟不上上一篇讲了 oplog 是复制的载体，Secondary 靠拉取重放 oplog 追 Primary。但「追」这个动作不是实时的，Secondary 总会有一点点延迟。少量延迟正常，但持续的大延迟是问题——它会让读 Secondary 的应用拿到过时数据，更严重的是，failover 时延迟的数据可能丢失（回滚）。

葫芦和十三

图解 MongoDB 17｜大集合与工作集：数据超过内存怎么办存储引擎阶段的前几篇，分别讲了 B+-tree 页、Cache 淘汰、journal、压缩。这一篇把它们收束到一个最实际的运维问题：当数据量超过内存时怎么办。这是 MongoDB 部署里迟早会遇到、也最容易判断错的容量拐点。

葫芦和十三

图解 MongoDB 18｜复制集拓扑：Primary、Secondary 和 Arbiter 的分工存储引擎阶段回答了「数据怎么存、怎么不丢」，但留下一个致命问题：单机宕机了怎么办。一台 mongod 进程挂掉，不管是硬件故障、进程崩溃还是网络隔离，所有读写都会中断。这在生产环境是不可接受的。

葫芦和十三

图解 MongoDB 15｜journal 与持久化：写入怎么不丢，崩溃怎么恢复上一篇讲 Cache 淘汰，回答了「查询为什么会抖」。这一篇讲 journal 和持久化，回答另一个根本问题：写入怎么保证不丢，崩溃后怎么恢复。这是所有数据库都必须回答的问题，MongoDB 的答案落在 journal（预写日志）和 checkpoint 这套机制上。

葫芦和十三

图解 MongoDB 16｜压缩：snappy、zstd 和 zlib 的取舍讲完 journal 和持久化，这一篇讲存储引擎阶段的最后一个机制——压缩。它看起来只是「省磁盘」的功能，但实际上压缩同时影响三个性能维度：磁盘占用、Cache 效率、CPU 开销。选错压缩方式，要么浪费存储，要么把 CPU 打满，要么拖慢查询。

葫芦和十三

图解 MongoDB 13｜WiredTiger 存储引擎：B-tree、页和 checkpoint 三件套前两个阶段讲的索引、查询、explain，都停在了「逻辑层」。我们知道了查询怎么走索引、怎么回表，但没回答一个更底层的问题：这些索引和数据，到底在内存里还是磁盘上，查询快慢的真正分界线在哪。

葫芦和十三

图解 MongoDB 14｜Cache 与淘汰：WiredTiger 的内存治理上一篇把 WiredTiger 的 B-tree 页、Cache 和 checkpoint 三件套铺开了，这一篇聚焦其中最敏感的部分——Cache 的淘汰机制。它是 MongoDB 性能抖动最直接的来源：查询平时很快，突然变慢，往往就是 Cache 淘汰出了问题。

葫芦和十三

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

葫芦和十三

图解 MongoDB 11｜慢查询排查闭环：从 Profile 到 explain 的分层路径线上 MongoDB 慢了，最本能的反应是「加个索引试试」。但这是排查慢查询里最坏的开局——既可能加错索引（没解决根因），又可能加多索引（拖慢写入）。正确的做法是先定位慢查询，搞清楚它慢在哪一层，再有针对性地动手。

葫芦和十三

图解 MongoDB 09｜explain 再读：从 queryPlanner 到 executionStats前面两篇讲了索引类型和 ESR 原则，但所有这些设计到底有没有生效，只有一个验证手段：explain。问题是，很多人用 explain 的方式是「跑一下，看有没有 IXSCAN 字样」，看完就走了。这种用法只用了 explain 一成的能力，错过了它真正值钱的部分——查询到底扫了多少、回表了多少、慢在哪。

葫芦和十三

图解 MongoDB 10｜覆盖查询：让索引把活干完，根本不用回表上一篇讲 explain 时，提到一个理想状态：totalDocsExamined = 0。意思是查询根本没回表读文档，所有需要的数据都在索引里拿到了。这个状态叫覆盖查询（covered query），是 MongoDB 查询优化的一个重要终点——它把查询从「索引定位 + 回表读取」压缩成「索引定位即完成」，少一次 B-tree 跳转、少一次页读取。

葫芦和十三

图解 MongoDB 08｜ESR 原则：复合索引的字段顺序怎么定复合索引是 MongoDB 性能优化里最常用、也最容易用错的工具。很多人建复合索引的方式是「查询用到哪几个字段，就按想到的顺序建一个」，结果发现索引只用了第一个字段，查询照样慢。问题不在「有没有建索引」，而在字段顺序。

葫芦和十三

图解 MongoDB 07｜索引类型：七种索引，七种访问形状上一篇把索引讲成了 WiredTiger 里的独立 B-tree，回答了「索引是什么、为什么查得快写得慢」。但那只解决了索引的「共性」，没解决最实际的问题：我的查询到底该建哪种索引。

葫芦和十三

图解 MongoDB 06｜模式演进：无 schema 是优势还是债「MongoDB 不需要建表，加字段直接存就行」——这句话是 MongoDB 最出圈的卖点，也是最容易被误解的一条。它听起来像是「结构可以随便长」，但真实情况是：schemaless 不是「没有结构」，而是「结构被推到了应用层」。数据库不再替你把关字段类型和必填，这份责任全转给了代码。

葫芦和十三

图解 MongoDB 05｜文档模型设计：内嵌 vs 引用，反范式不是免费午餐刚从 MySQL 迁到 MongoDB 的人，最容易把关系建模那一套照搬过来：每个实体建一个集合，用 userId、orderId 这种字段做关联，查询时再 $lookup 拼。这种写法能跑，但它把 MongoDB 用成了「没有外键约束的关系库」，丢掉了文档模型最大的优势——访问局部性。

葫芦和十三

图解 MongoDB 03｜CRUD 全链路：一条 find 怎么穿过 WiredTiger写过 MongoDB 的人对 db.users.find({age: {$gt: 18}}) 都很熟，但很少有人能说清这条查询从发出到返回，中间到底走了几段路。在接口层，它就是「查文档」；可一旦你要排查「为什么这条查询慢」，就必须知道它卡在链路的哪一段。

葫芦和十三

图解 MongoDB 04｜索引模型：每建一个索引，就是在 B+-tree 森林里多栽一棵用过 MongoDB 的人都知道 createIndex，也多半背过「加索引能让查询变快」。但这个说法停留在接口层，掩盖了索引真正的本质：MongoDB 的索引不是「字段上的标记」，而是 WiredTiger 里一棵独立的 B+-tree。每建一个索引，就是在存储引擎的 B+-tree 森林里多栽一棵树。

葫芦和十三

图解 MongoDB 02｜BSON：你以为存的是 JSON，其实是带类型的二进制很多人第一次用 MongoDB，看到 find() 返回一个 JavaScript 对象，就自然以为「MongoDB 存的是 JSON」。这个认知在应用层成立，但一旦往下看一层就会失效：driver、mongod、WiredTiger 之间流动的根本不是 JSON 文本，而是 BSON——一种带类型标记和长度前缀的二进制格式。

葫芦和十三

图解 MongoDB 01｜文档数据库很多 MongoDB 的入门材料把它介绍成「一个用 JSON 存数据的数据库」，讲到 db.users.insertOne({...}) 就结束了。这个说法在接口层没错，但它把重点带偏了：MongoDB 不是一个「JSON 仓库」，而是由 driver、mongod 和存储引擎三段路拼出来的系统。