> 本文是写作规划，不是可发布正文。拆解对象：MongoDB 默认存储引擎 WiredTiger——Cache / Eviction / B-Tree update chain / Reconciliation / Timestamps·Snapshot / History Store / Checkpoint·Jou…

本文介绍WiredTiger作为MongoDB默认存储引擎的内核机制，定位为文档库页式B-Tree加旁路History Store，与PG/InnoDB、SQLite、RocksDB等分工明确。文章规划17篇系列，涵盖Session、Cache、Eviction、Reconciliation、Timestamps、Checkpoint等核心流程，并指出脏页须先reconcile才能驱逐，HS体积受更新率与窗口影响，为后续深入解析奠定框架。

本文介绍WiredTiger存储引擎中Connection、Session、Cursor三层句柄的生命周期与线程模型。Connection独占数据库实例，Session单线程且同时仅持有一个事务，Cursor由Session拥有并共享事务上下文。文章强调多线程应共享Connection但各自持有Session，并澄清常见误解，为后续Cache与Eviction章节铺垫。

本文介绍WiredTiger存储引擎的缓存机制。缓存按需加载B-Tree页，WT_REF表示页是否在内存，WT_PAGE是已加载形态。缓存计量区分clean和dirty页，dirty页必须经reconcile转换后才能写盘。修改通过WT_UPDATE链和WT_INSERT跳表记录，session和cursor不计入缓存配额。与PostgreSQL不同，WT将内存布局与磁盘格式分离，并支持共享缓存模式。

WiredTiger的Eviction机制通过server线程近似LRU选页，worker线程执行驱逐，区分clean（直接释放）和dirty（需reconcile，最新值进用户表，旧版进History Store）。配置target/trigger控制后台或应用线程参与驱逐，dirty超限时应用线程被迫协助。Eviction也是checkpoint前置减压阀，HS页同样参与驱逐。

本文介绍WiredTiger存储引擎中B-Tree叶页的内存结构：新键通过WT_INSERT skiplist插入，已有键的修改挂入WT_UPDATE链表，未提交更新仅挂链不写入磁盘。读路径按时间戳在链上查找可见版本，旧版本在reconcile时移入History Store。文章还提及truncate操作及与日志回放的边界，为后续Reconciliation章节铺垫。

WiredTiger的reconciliation将内存页转为磁盘格式，触发于脏页驱逐和检查点。用户表保留最新已提交更新，旧版本写入History Store。行存储叶页按序遍历，依leaf_page_max和split_pct分裂为多页镜像。History Store页reconcile时移除全局可见墓碑。Eviction为腾缓存，Checkpoint为一致快照，两者分工明确。

本文介绍WiredTiger存储引擎的时间戳与快照机制。核心概念包括：应用时间戳由上层控制，执行时间是墙上时钟；active time window由oldest、stable、pinned界定可读与可丢弃历史；快照通过max/min/并发事务ID列表决定可见性；默认snapshot隔离，prepared事务有特殊边界。文章强调时间戳与快照共同支撑MongoDB的MVCC实现。

本文介绍WiredTiger存储引擎的Checkpoint机制，作为崩溃恢复的已知时间点，与日志共同保证耐久性。流程包括加锁、eviction减压、准备、用户表reconcile、History Store（故意后置以包含新增写入）、落盘及元数据更新。通过generation防止eviction超前，支持并行checkpoint，并与Journal分工协作。

本文介绍WiredTiger日志系统：WAL文件为WiredTigerLog.*，预分配用Tmplog/Preplog；提交时写commit记录，崩溃恢复从最近checkpoint回放；热路径用lock-free slot池，内部线程分工；backup cursor打开时禁用自动删除和预分配。

本文介绍WiredTiger的Rollback to Stable（RTS）机制：当stable时间戳落后于durable或存在未提交事务时，RTS扫描表并移除不稳定修改，保留稳定版本。它跳过logged表，需独占数据库，完成后常执行checkpoint。RTS通过时间聚合减少读页，并处理History Store中的不稳定条目，确保恢复后数据一致性。

本文介绍WiredTiger存储引擎的Block Manager子系统。每个数据文件由若干块组成，采用无覆盖分配策略，重写时写入新位置。块通过address cookie寻址，包含偏移、大小和校验和。分配使用best fit或first fit策略，checkpoint维护alloc、avail、discard三张extent列表管理空间。写入时计算校验和，支持压缩。旧checkpoint删除后块才可复用。

本文介绍WiredTiger存储引擎的compaction机制：通过将文件尾部块前移到可复用区间，再多次checkpoint后truncate缩小文件，但为best-effort不保证成功。同时说明backup cursor打开期间禁用日志删除与预分配改名，保证备份一致性，但会导致日志堆积，备份窗口应有界。

本文介绍MongoDB手册中WiredTiger存储引擎的运维参数映射：缓存大小、约60秒检查点、日志与历史窗口等旋钮对应内核机制；列出数据目录关键文件（.wt、WiredTigerHS.wt、日志等）；明确不展开复制集、分片等边界；强调调参前需回看机制篇，避免误操作。

本文介绍WiredTiger排障方法，强调禁止删除HS或日志文件、多实例写同一路径。按现象分类：HS增长查历史窗口与长事务；缓存压力查dirty与eviction；长游标拖住历史回收；日志堆积因备份游标泄漏；启停慢因RTS与HS体积。建议观测serverStatus、文件大小与应用慢查询，并记录版本与采样时间。

本文对比PostgreSQL、InnoDB、RocksDB和WiredTiger四种存储引擎，从缓存、脏页、WAL、MVCC落点、旧版本回收及故障形态等维度列出机制对照表，强调机制与代价而非性能排名。指出WiredTiger区分内存与磁盘页，HS存储旧版本，并提醒避免跨引擎类比运维参数，为选型提供参考。

本文为WiredTiger内核系列终篇，提供选型决策树：文档模型且需MongoDB生态选WiredTiger；否则按需选PG/InnoDB、SQLite或RocksDB。同时回收开放问题，给出17篇阅读地图，强调脏页需reconcile、旧版进History Store，并指出选WT应基于文档生态而非性能承诺。

本文介绍WiredTiger内核系列文章，涵盖MongoDB默认引擎的MVCC实现路径，包括Cache、Eviction、Reconciliation、History Store和Checkpoint等核心机制。系列共17篇，从Session/Cursor到选型对照，重点解析更新链、脏页驱逐、旧快照读取及崩溃恢复，并对比PG、InnoDB、RocksDB等引擎，为运维和架构师提供完整技术参考。

WiredTiger采用第三种MVCC方案：用户表B-Tree仅存最新已提交版本，旧版本存入全局History Store（WiredTigerHS.wt）。写路径通过reconciliation将旧版本写入HS，读路径按update chain→磁盘页→HS顺序查找。Durable History取代Lookaside，使历史可跨eviction/checkpoint持久查询，由minSnapshotHistoryWindowInSeconds控制保留窗口。与PostgreSQL堆版本、InnoDB undo相比，WT分离当前与历史，利于用户页驱逐，但增加历史I/O与磁盘开销。

WiredTiger通过History Store实现MVCC：用户表仅存最新已提交版本，旧版本存入独立的WiredTigerHS.wt文件。读路径按update chain→磁盘页→History Store顺序查找。相比Lookaside，Durable History提供跨eviction/checkpoint的可查询历史契约，由minSnapshotHistoryWindowInSeconds控制保留窗口。与PG堆版本、InnoDB undo相比，WT将当前与历史分离，利于用户页驱逐，但增加历史I/O与磁盘开销。