【WiredTiger 内核】选型与阅读地图：何时 MongoDB / WiredTiger
内容提要
本文为WiredTiger内核系列终篇，提供选型决策树：文档模型且需MongoDB生态选WiredTiger；否则按需选PG/InnoDB、SQLite或RocksDB。同时回收开放问题，给出17篇阅读地图，强调脏页需reconcile、旧版进History Store，并指出选WT应基于文档生态而非性能承诺。
延伸解读
选型决策树的核心逻辑
本文的决策树以“文档模型是否为主”为第一分支，而非性能对比。若文档模型是硬需求，再判断是否需要 MongoDB 生态（复制、分片、查询）；若仅需 WiredTiger 库，可嵌入使用但需自行改写运维参数。若不需要文档模型，则按 SQL 需求、部署形态（进程内或嵌入式）和写模式（高写入 KV）分别选择 PG/InnoDB、SQLite 或 RocksDB。这提示选型应基于数据模型和生态匹配，而非单一性能指标。
负向信号：选型前的警示
文章明确列出三个负向信号，提醒读者在选 WT/MongoDB 前需谨慎：一是期望“小字段更新只占小历史”，但文档整值进 History Store 可能不符合直觉；二是要求未实测的跨引擎尾延迟对比，本站拒绝提供；三是将复制/分片问题简单归咎于 cacheSizeGB 调优。这些信号帮助读者避免常见误解，强调机制理解优先于参数调整。
开放问题与阅读地图的价值
系列回收了三个开放问题，均标注为“需实测”，并给出对应篇目入口，体现“把问题钉在 Guide/源码路径上”的严谨态度。阅读地图将 17 篇分为模型与缓存、写路径与版本、持久化与恢复、磁盘与嵌入、对照与选型五部分，并推荐核心阅读顺序 1→3→4→6→8→9→17。这为读者提供了系统学习路径，避免碎片化阅读。
Q&A
什么时候应该选择 MongoDB 和 WiredTiger？
当工作负载以文档模型为主，并且需要 MongoDB 的复制、分片、查询等生态功能时，应选择 MongoDB 和 WiredTiger。如果只需要 WiredTiger 库而不需要文档服务器，也可以直接嵌入 WiredTiger。
如果不需要文档模型，应该选择什么数据库引擎？
如果不需要文档模型，根据需求选择：需要标准 SQL、复杂事务和约束时选 PostgreSQL 或 InnoDB；需要进程内 SQL、单写者时选 SQLite；需要嵌入式有序 KV、写优化时选 RocksDB。
选择 WiredTiger 前有哪些负面信号需要注意？
负面信号包括：期望小字段更新只占用小历史空间（但文档整值进 History Store 可能不符合直觉）；需要未实测的跨引擎尾延迟对比；把复制或分片问题简单归因于 cacheSizeGB 调整。
WiredTiger 中脏页和旧版本数据是如何处理的？
脏页需要经过 reconcile 处理，最新数据保留在用户表中，旧版本数据进入 History Store。旧快照的读取依赖更新链、磁盘和 History Store。
WiredTiger 内核系列文章推荐的必读顺序是什么？
推荐的必读顺序是：1 → 3 → 4 → 6 → 8 → 9 → 17。
WiredTiger 与 PostgreSQL、InnoDB、SQLite、RocksDB 的分工是怎样的？
WiredTiger 是文档库默认引擎，适合文档模型和 MongoDB 生态；PostgreSQL/InnoDB 适合标准 SQL 和复杂事务；SQLite 适合嵌入式单写者场景；RocksDB 适合嵌入式有序 KV 和写优化。它们分工清晰，选择 WiredTiger 通常基于 MongoDB 文档生态而非性能承诺。
