一、前言

在进行高性能 Java 持久性培训时，我意识到有必要解释关系数据库的工作原理，否则，很难把握许多与事务相干的概念，例如原子性、持久性和检查点。

在这篇文章中，我将对关系数据库的外部工作形式进行高层次的解释，同时还暗示一些特定于数据库的实现细节。

二、一图胜千文

三、Data pages

磁盘访问速度很慢。另一方面，内存甚至比固态硬盘还要快几个数量级。出于这个起因，数据库供应商试图尽可能提早磁盘拜访。无论咱们议论的是表还是索引，数据都被分成肯定大小（例如 8 KB）的 page。

当须要读取数据（表或索引）时，关系数据库会将基于磁盘的页面映射到内存缓冲区。当须要批改数据时，关系数据库会更改内存 pages。要将内存 pages 与磁盘同步，必须进行 flush（例如 fsync）。

存储基于磁盘的 page 的缓冲池大小无限，因而通常须要存储数据工作集。只有当整个数据能够放入内存时，缓冲池能力存储整个数据集。
然而，如果须要缓存新 page 时磁盘上的总体数据大于缓冲池大小，则缓冲池将不得不逐出旧 pages 为新 pages 腾出空间。

四、Undo log

因为内存中的变动能够被多个并发事务拜访，所以必须采纳并发管制机制（例如 2PL 和 MVCC）来确保数据完整性。因而，一旦事务批改了表行，未提交的更改将利用于内存构造，而先前的数据会长期存储在 undo log append-only 构造中。

尽管这种构造在 Oracle 和 MySQL 中称为 undo log，但在 SQL Server 中，事务日志起着这种作用。PostgreSQL 没有 undo log，然而通过多版本表构造达到了雷同的目标，因为表能够存储同一行的多个版本。然而，所有这些数据结构都用于提供回滚能力，这是原子性的强制性要求。

如果以后运行的事务回滚，undo log 将用于重建事务开始时的内存 pages。

五、Redo log

一旦事务提交，内存中的更改必须放弃不变。然而，这并不意味着每个事务提交都会触发 fsync。事实上，这对应用程序性能十分不利。然而，从 ACID 事务属性，咱们晓得提交的事务必须提供持久性，这意味着即便咱们拔掉数据库引擎，提交的更改也须要长久化。

那么，关系数据库如何提供持久性而不在每次事务提交时收回 fsync 呢？

这就是 redo log 发挥作用的中央。redo log 也是一种 append-only 基于磁盘的构造，用于存储给定事务所经验的每个更改。因而，当事务提交时，每个数据页更改也将写入_redo log_。与刷新固定数量的 data pages 相比，写入 redo log 十分快，因为程序磁盘拜访比 Random access 快得多。因而，它还容许事务疾速解决。

尽管这种构造在 Oracle 和 MySQL 中被称为 redo log，但在 SQL Server 中，事务日志也扮演着这个角色。PostgreSQL 将其称为预写日志 (WAL)。

然而，何时将内存中的更改 flush 到磁盘？

关系数据库系统应用检查点将内存中的脏 pages 与其基于磁盘的对应物同步。为防止 IO 流量拥塞，同步通常在较长的时间段内分块实现。

然而，如果关系数据库在将所有脏内存 pages 刷新到磁盘之前解体会产生什么？

万一产生解体，在启动时，数据库将应用 redo log 重建自上次胜利检查点以来未同步的基于磁盘的 data pages。

六、论断

采纳这些设计思考是为了克服基于磁盘的存储的高提早，同时依然提供持久性存储保障。因而，须要 undo log 来提供原子性（回滚能力），而须要 redo log 来确保基于磁盘的 page（表和索引）的持久性。

七、译者说：

大家好，我是 如梦技术 春哥（mica 开源作者）翻译不易，请帮忙分享给更多的同学，谢谢！！！