【WiredTiger 内核】与 PG / InnoDB / RocksDB 机制对照
内容提要
本文对比PostgreSQL、InnoDB、RocksDB和WiredTiger四种存储引擎，从缓存、脏页、WAL、MVCC落点、旧版本回收及故障形态等维度列出机制对照表，强调机制与代价而非性能排名。指出WiredTiger区分内存与磁盘页，HS存储旧版本，并提醒避免跨引擎类比运维参数，为选型提供参考。
延伸解读
机制对照的价值在于排除错误类比
文章强调对照表用于排除错误类比，如“HS 就是 undo”“cacheSize 等于 shared_buffers”。这些类比看似合理，但底层机制不同：HS 存储的是文档级旧版本，而 undo 是行级变更记录；cacheSize 与 shared_buffers 在缓存粒度、脏页处理上均有差异。理解这些差异，可避免在运维中直接套用其他引擎的参数或经验。
MVCC 落点决定空间与回收行为
四种引擎的 MVCC 落点各异：PG 在堆内保存新旧元组，InnoDB 用 undo 旁路，WiredTiger 将旧版本存入 History Store，RocksDB 则在 SST 中保留多版本键。这直接影响旧版本回收机制：PG 依赖 VACUUM，InnoDB 靠 purge，WT 依赖 HS tombstone 与窗口，RocksDB 靠 compaction。选型时需考虑更新模式与空间增长。
故障形态各有侧重，排障入口不同
文章指出各引擎典型故障形态：PG 表膨胀、InnoDB undo history 过长、RocksDB 写停顿与 L0 堆积、WiredTiger HS 膨胀与 dirty eviction 尖刺。排障时需针对引擎特性定位，例如 WT 关注 HS 与脏驱逐，RocksDB 关注 L0 层数。了解这些差异有助于快速诊断问题。
Q&A
WiredTiger 与 PostgreSQL、InnoDB、RocksDB 在缓存机制上有何不同？
WiredTiger 显式区分内存页和磁盘页，脏页离开缓存时需进行 reconcile 并可能写入 History Store；PostgreSQL 和 InnoDB 的缓冲池中页面格式接近磁盘页，差异较小；RocksDB 前台写入走 MemTable，持久化形态为 SST，与页式 reconcile 不同。
WiredTiger 如何实现持久性？
WiredTiger 通过 checkpoint 固定一致点，journal 覆盖间隙，并使用 RTS（Read Timestamp）处理时间戳不稳定侧，确保持久性。
四种存储引擎的 MVCC 旧版本存储位置分别在哪里？
PostgreSQL 将新旧元组都放在堆表中，旧版本通过 VACUUM 回收；InnoDB 将旧版本存储在 Undo 中；WiredTiger 将旧版本存储在 History Store（HS.wt）中；RocksDB 等 LSM 引擎将多版本键存储在 SST 中，通过 Compaction 回收。
WiredTiger 的 History Store 与 InnoDB 的 Undo 有何区别？
WiredTiger 的 History Store 存储旧版本，而 InnoDB 的 Undo 也存储旧版本，但两者在实现和空间模型上不同。文章指出不能简单类比，例如 HS 与 undo 在小字段高频更新下的空间曲线需实测，且 HS 存储整值，与“改一个字段”的直觉不对齐。
WiredTiger 的典型故障形态是什么？
WiredTiger 的典型故障形态包括 History Store 膨胀和 dirty eviction 尖刺。
为什么不能将 WiredTiger 的 cacheSize 直接等同于 PostgreSQL 的 shared_buffers？
因为不同存储引擎的缓存机制和代价不同，WiredTiger 区分内存页和磁盘页，脏页写出需 reconcile 并可能写 HS，而 PostgreSQL 的缓冲池页面接近磁盘页。跨引擎类比运维参数会导致错误，应避免照搬数值。
