内存漫游

MVCC（多版本并发控制）通过维护数据的多个版本，解决事务并发读取时的可见性问题。它允许不同事务根据自身快照看到不同版本的数据，确保读写不阻塞。旧版本不会立即删除，因可能被未提交事务需要。

前面的文章已经从存储一路走到了 WAL： 到这里，数据库已经能够回答一个重要问题： “如果数据库突然崩溃，已经提交的数据怎么恢复？” 但还有一个更复杂的问题： 这就是这次要进入的主题。

WAL（预写日志）是数据库保障数据持久性的核心机制。其核心思想是：修改数据页前，必须先将变更记录写入日志并持久化。即使内存中的脏页未及时写回磁盘，崩溃后也可通过重放日志（Redo）恢复数据。

如果说 Page 解决的是“数据如何组织”，那么 Buffer Pool 解决的就是：哪些数据应该留在内存里？什么时候读进来？什么时候淘汰？什么时候写回磁盘？

如果一页只有 8KB、16KB，而记录大小又各不相同，数据库究竟如何知道一条记录在哪里、哪里还有空间，以及删除和更新之后如何继续使用这些空间？

本文比较了SQLite、PostgreSQL和MySQL InnoDB三种数据库在B-Tree索引实现上的核心差异。

从最直接的全表扫描，到看起来已经足够高效的二分查找，再到真正面向数据库存储模型设计的 B+Tree，这背后并不只是数据结构的变化，而是一次从 算法 、Page、 I/O、 数据访问模式。

本文从最底层的字节流出发，一步步拆解 PostgreSQL、MySQL InnoDB 与 SQLite 的数据组织哲学，理清 Page Header、Tuple 以及 Index 如何联动协同。

数据库设计思想探讨，文件存储的局限、索引的快速查找、存储引擎的职责、事务的ACID保证、并发控制的必要性，及数据库的四大类。