若是有人问你数据库的原理，叫他看这篇文章（三）

本文由 伯乐在线 - Panblack 翻译，黄利民 校稿。

英文出处：Christophe Kalenzaga。

（接上文）

数据治理器

在这一步，查询治理器执行了查询，需要从表和索引获取数据，于是向数据治理器提出请求。可是有 2 个问题：

• 关系型数据库使用事务模子，以是，当其他人在统一时刻使用或修改数据时，你无法获得这部门数据。
• 数据提取是数据库中速率最慢的操作，以是数据治理器需要足够智慧地获得数据并生存在内存缓冲区内。

在这一部门，我没看看关系型数据库是怎样处置惩罚这两个问题的。我不会讲数据治理器是怎么获得数据的，由于这不是最主要的（而且本文已经够长的了！）。

缓存治理器

我已经说过，数据库的主要瓶颈是磁盘 I/O。为了提高性能，现代数据库使用缓存治理器。查询执行器不会直接从文件系统拿数据，而是向缓存治理器要。缓存治理器有一个内存缓存区，叫做缓冲池，从内存读取数据显著地提升数据库性能。对此很难给出一个数目级，由于这取决于你需要的是哪种操作：

• 顺序会见（好比：全扫描） vs 随机会见（好比：根据row id会见）
• 读照旧写

以及数据库使用的磁盘类型：

• 7.2k/10k/15k rpm的硬盘
• SSD
• RAID 1/5/…

要我说，内存比磁盘要快100到10万倍。然而，这导致了另一个问题（数据库总是这样…)，缓存治理器需要在查询执行器使用数据之前获得数据，否则查询治理器不得不等候数据从缓慢的磁盘中读出来。

预读

这个问题叫预读。查询执行器知道它将需要什么数据，由于它相识整个查询流，而且通过统计也相识磁盘上的数据。原理是这样的：

• 当查询执行器处置惩罚它的第一批数据时
• 会告诉缓存治理器预先装载第二批数据
• 当最先处置惩罚第二批数据时
• 告诉缓存治理器预先装载第三批数据，而且告诉缓存治理器第一批可以从缓存里清掉了。
• ……

缓存治理器在缓冲池里生存所有的这些数据。为了确定一条数据是否有用，缓存治理器给缓存的数据添加了分外的信息（叫闩锁）。有时查询执行器不知道它需要什么数据，有的数据库也不提供这个功效。相反，它们使用一种推测预读法（好比：若是查询执行器想要数据1、3、5，它不久后很可能会要 7、9、11），或者顺序预读法（这时间缓存治理器只是读取一批数据后简朴地从磁盘加载下一批一连数据）。为了监控预读的事情状态，现代数据库引入了一个怀抱叫缓冲/缓存掷中率，用来显示请求的数据在缓存中找到而不是从磁盘读取的频率。注：糟糕的缓存掷中率不总是意味着缓存事情状态不佳。更多信息请阅读Oracle文档。缓冲只是容量有限的内存空间，因此，为了加载新的数据，它需要移除一些数据。加载和扫除缓存需要一些磁盘和网络I/O的成本。若是你有个经常执行的查询，那么每次都把查询效果加载然后扫除，效率就太低了。现代数据库用缓冲区置换计谋来解决这个问题。

缓冲区置换计谋

多数现代数据库(至少 SQL Server, MySQL, Oracle 和 DB2)使用 LRU 算法。

LRU

LRU代表最近最少使用（Least Recently Used）算法，背后的原理是：在缓存里保留的数据是最近使用的，以是更有可能再次使用。图解：为了更好的明白，我假设缓冲区里的数据没有被闩锁锁住（就是说是可以被移除的）。在这个简朴的例子里，缓冲区可以生存 3 个元素：

• 1：缓存治理器（简称CM）使用数据1，把它放入空的缓冲区
• 2：CM使用数据4，把它放入半载的缓冲区
• 3：CM使用数据3，把它放入半载的缓冲区
• 4：CM使用数据9，缓冲区满了，以是数据1被扫除，由于它是最后一个最近使用的，数据9加入到缓冲区
• 5：CM使用数据4，数据4已经在缓冲区了，以是它再次成为第一个最近使用的。
• 6：CM使用数据1，缓冲区满了，以是数据9被扫除，由于它是最后一个最近使用的，数据1加入到缓冲区
• ……

这个算法效果很好，可是有些限制。若是对一个大表执行全表扫描怎么办？换句话说，当表/索引的巨细超出缓冲区会发生什么？使用这个算法会扫除之前缓存内所有的数据，而且全扫描的数据很可能只使用一次。

革新

为了防止这个征象，有些数据库增添了特殊的规则，好比Oracle文档中的形貌：『对很是大的表来说，数据库通常使用直接路径来读取，即直接加载区块[……]，来制止填满缓冲区。对于中等巨细的表，数据库可以使用直接读取或缓存读取。若是选择缓存读取，数据库把区块置于LRU的尾部，防止清空当前缓冲区。』另有一些可能，好比使用高级版本的LRU，叫做 LRU-K。例如，SQL Server 使用 LRU-2。这个算法的原理是把更多的历史记载思量进来。简朴LRU（也就是 LRU-1），只思量最后一次使用的数据。LRU-K呢：

• 思量数据最后第K次使用的情形
• 数据使用的次数加进了权重
• 一批新数据加载进入缓存，旧的可是经常使用的数据不会被扫除（由于权重更高）
• 可是这个算法不会保留缓存中不再使用的数据
• 以是数据若是不再使用，权重值随着时间推移而降低

盘算权重是需要成本的，以是SQL Server只是使用 K=2，这个值性能不错而且分外开销可以接受。关于LRU-K更深入的知识，可以阅读早期的研究论文（1993）：数据库磁盘缓冲的LRU-K页面置换算法其他算法固然另有其他治理缓存的算法，好比：

• 2Q（类LRU-K算法）
• CLOCK（类LRU-K算法）
• MRU（最新使用的算法，用LRU同样的逻辑但差别的规则）
• LRFU（Least Recently and Frequently Used，最近最少使用最近最不常用）
• ……

写缓冲区

我只探讨了读缓存 —— 在使用之前预先加载数据。用来生存数据、成批刷入磁盘，而不是逐条写入数据从而造成许多单次磁盘会见。要记着，缓冲区生存的是页（最小的数据单元）而不是行（逻辑上/人类习惯的视察数据的方式）。缓冲池内的页若是被修改了但还没有写入磁盘，就是脏页。有许多算法来决议写入脏页的最佳时机，但这个问题与事务的观点高度关联，下面我们就谈谈事务。

事务治理器

最后但同样主要的，是事务治理器，我们将看到这个历程是怎样保证每个查询在自己的事务内执行的。但最先之前，我们需要明白ACID事务的观点。

“I’m on acid”

一个ACID事务是一个事情单元，它要保证4个属性：

• 原子性（Atomicity）: 事务『要么所有完成，要么所有作废』，纵然它连续运行10个小时。若是事务瓦解，状态回到事务之前（事务回滚）。
• 隔离性（Isolation）: 若是2个事务 A 和 B 同时运行，事务 A 和 B 最终的效果是相同的，不管 A 是竣事于 B 之前/之后/运行时代。
• 持久性（Durability）: 一旦事务提交（也就是乐成执行）,不管发生什么（瓦解或者堕落），数据要生存在数据库中。
• 一致性（Consistency）: 只有正当的数据（遵照关系约束和函数约束）能写入数据库，一致性与原子性和隔离性有关。

在统一个事务内，你可以运行多个SQL查询来读取、建立、更新和删除数据。当两个事务使用相同的数据，贫苦就来了。经典的例子是从账户A到账户B的汇款。假设有2个事务：

• 事务1（T1）从账户A取出100美元给账户B
• 事务2（T2）从账户A取出50美元给账户B

我们回来看看ACID属性：

• 原子性确保不管 T1 时代发生什么（服务器瓦解、网络中止…），你不能泛起账户A 取走了100美元但没有给账户B 的征象（这就是数据纷歧致状态）。
• 隔离性确保若是 T1 和 T2 同时发生，最终A将淘汰150美元，B将获得150美元，而不是其他效果，好比由于 T2 部门抹除了 T1 的行为，A淘汰150美元而B只获得50美元（这也是纷歧致状态）。
• 持久性确保若是 T1 刚刚提交，数据库就发生瓦解，T1 不会消逝得无影无踪。
• 一致性确保钱不会在系统内天生或灭失。

[以下部门不主要，可以跳过]现代数据库不会使用纯粹的隔离作为默认模式，由于它会带来庞大的性能消耗。SQL一样平常界说4个隔离级别：

• 串行化(Serializable，SQLite默认模式）：最高级此外隔离。两个同时发生的事务100%隔离，每个事务有自己的『天下』。
• 可重复读（Repeatable read，MySQL默认模式）：每个事务有自己的『天下』，除了一种情形。若是一个事务乐成执行而且添加了新数据，这些数据对其他正在执行的事务是可见的。可是若是事务乐成修改了一条数据，修改效果对正在运行的事务不行见。以是，事务之间只是在新数据方面突破了隔离，对已存在的数据仍然隔离。
  举个例子，若是事务A运行”SELECT count(1) from TABLE_X” ，然后事务B在 TABLE_X 加入一条新数据并提交，当事务A再运行一次 count(1)效果不会是一样的。
  这叫幻读（phantom read）。
• 读取已提交（Read committed，Oracle、PostgreSQL、SQL Server默认模式）：可重复读+新的隔离突破。若是事务A读取了数据D，然后数据D被事务B修改（或删除）并提交，事务A再次读取数据D时数据的转变（或删除）是可见的。
  这叫不行重复读（non-repeatable read）。
• 读取未提交（Read uncommitted）：最低级此外隔离，是读取已提交+新的隔离突破。若是事务A读取了数据D，然后数据D被事务B修改（但并未提交，事务B仍在运行中），事务A再次读取数据D时，数据修改是可见的。若是事务B回滚，那么事务A第二次读取的数据D是无意义的，由于那是事务B所做的从未发生的修改（已经回滚了嘛）。
  这叫脏读（dirty read）。

多数数据库添加了自界说的隔离级别（好比 PostgreSQL、Oracle、SQL Server的快照隔离），而且并没有实现SQL规范里的所有级别（尤其是读取未提交级别）。默认的隔离级别可以由用户/开发者在建设毗连时笼罩（只需要增添很简朴的一行代码）。

并发控制

确保隔离性、一致性和原子性的真正问题是对相同数据的写操作（增、更、删）：

• 若是所有事务只是读取数据，它们可以同时事情，不会更改另一个事务的行为。
• 若是（至少）有一个事务在修改其他事务读取的数据，数据库需要找个措施对其它事务隐藏这种修改。而且，它还需要确保这个修改操作不会被另一个看不到这些数据修改的事务擦除。

这个问题叫并发控制。最简朴的解决措施是依次执行每个事务（即顺序执行），但这样就完全没有伸缩性了，在一个多处置惩罚器/多核服务器上只有一个焦点在事情，效率很低。理想的措施是，每次一个事务建立或作废时：

• 监控所有事务的所有操作
• 检查是否2个（或更多）事务的部门操作由于读取/修改相同的数据而存在冲突
• 重新编排冲突事务中的操作来淘汰冲突的部门
• 根据一定的顺序执行冲突的部门（同时非冲突事务仍然在并发运行）
• 思量事务有可能被作废

用更正规的说法，这是对冲突的调理问题。更详细点儿说，这是个很是难题而且CPU开销很大的优化问题。企业级数据库无法负担等候几个小时，来寻找每个新事务运动最好的调理，因此就使用不那么理想的方式以制止更多的时间铺张在解决冲突上。

锁治理器

为相识决这个问题，多数数据库使用锁和/或数据版本控制。这是个很大的话题，我会集中探讨锁，和一点点数据版本控制。

灰心锁

原理是：

• 若是一个事务需要一条数据
• 它就把数据锁住
• 若是另一个事务也需要这条数据
• 它就必须要品级一个事务释放这条数据
  这个锁叫排他锁。

可是对一个仅仅读取数据的事务使用排他锁很是昂贵，由于这会迫使其它只需要读取相同数据的事务等候。因此就有了另一种锁，共享锁。共享锁是这样的：

• 若是一个事务只需要读取数据A
• 它会给数据A加上『共享锁』并读取
• 若是第二个事务也需要仅仅读取数据A
• 它会给数据A加上『共享锁』并读取
• 若是第三个事务需要修改数据A
• 它会给数据A加上『排他锁』，可是必须等候另外两个事务释放它们的共享锁。

同样的，若是一块数据被加上排他锁，一个只需要读取该数据的事务必须等候排他锁释放才气给该数据加上共享锁。锁治理器是添加和释放锁的历程，在内部用一个哈希表生存锁信息（要害字是被锁的数据），而且相识每一块数据是：

• 被哪个事务加的锁
• 哪个事务在等候数据解锁

死锁

可是使用锁会导致一种情形，2个事务永远在等候一块数据：

在本图中：

• 事务A 给 数据1 加上排他锁而且等候获取数据2
• 事务B 给 数据2 加上排他锁而且等候获取数据1

这叫死锁。在死锁发生时，锁治理器要选择作废（回滚）一个事务，以便消除死锁。这可是个艰难的决议：

• 杀死数据修改量最少的事务（这样能淘汰回滚的成本）？
• 杀死连续时间最短的事务，由于其它事务的用户等的时间更长？
• 杀死能用更少时间竣事的事务（制止可能的资源饥荒）？
• 一旦发生回滚，有几多事务会受到回滚的影响？

在作出选择之前，锁治理器需要检查是否有死锁存在。哈希表可以看作是个图表（见上文图），图中泛起循环就说明有死锁。由于检查循环是昂贵的（所有锁组成的图表是很重大的），经常会通过简朴的途径解决：使用超时设定。若是一个锁在超时时间内没有加上，那事务就进入死锁状态。锁治理器也可以在加锁之前检查该锁会不会酿成死锁，可是想要完善的做到这一点照旧很昂贵的。因此这些预检经常设置一些基本规则。两段锁实现纯粹的隔离最简朴的要领是：事务最先时获取锁，竣事时释放锁。就是说，事务最先前必须等候确保自己能加上所有的锁，当事务竣事时释放自己持有的锁。这是行得通的，可是为了等候所有的锁，大量的时间被铺张了。更快的要领是两段锁协议（Two-Phase Locking Protocol，由 DB2 和 SQL Server使用），在这里，事务分为两个阶段：

• 发展阶段：事务可以获得锁，但不能释放锁。
• 缩短阶段：事务可以释放锁（对于已经处置惩罚完而且不会再次处置惩罚的数据），但不能获得新锁。

这两条简朴规则背后的原理是：

• 释放不再使用的锁，来降低其它事务的等候时间
• 防止发生这类情形：事务最初获得的数据，在事务最先后被修改，当事务重新读取该数据时发生纷歧致。

这个规则可以很好地事情，但有个破例：若是修改了一条数据、释放了关联的锁后，事务被作废（回滚），而另一个事务读到了修改后的值，但最后这个值却被回滚。为了制止这个问题，所有独占锁必须在事务竣事时释放。多说几句固然了，真实的数据库使用更庞大的系统，涉及到更多类型的锁（好比意向锁，intention locks）和更多的粒度（行级锁、页级锁、分区锁、表锁、表空间锁），可是原理是相同的。我只探讨纯粹基于锁的要领，数据版本控制是解决这个问题的另一个要领。版本控制是这样的：

• 每个事务可以在相同时刻修改相同的数据
• 每个事务有自己的数据拷贝（或者叫版本）
• 若是2个事务修改相同的数据，只接受一个修改，另一个将被拒绝，相关的事务回滚（或重新运行）

这将提高性能，由于：

• 读事务不会壅闭写事务
• 写事务不会壅闭读
• 没有『臃肿缓慢』的锁治理器带来的分外开销

除了两个事务写相同数据的时间，数据版本控制各个方面都比锁体现得更好。只不外，你很快就会发现磁盘空间消耗庞大。数据版本控制和锁机制是两种差别的看法：乐观锁和灰心锁。两者各有利弊，完全取决于使用场景（读多照旧写多）。关于数据版本控制，我推荐这篇很是优异的文章，讲的是PostgreSQL怎样实现多版本并发控制的。一些数据库，好比DB2（直到版本 9.7）和 SQL Server（不含快照隔离）仅使用锁机制。其他的像PostgreSQL, MySQL 和 Oracle 使用锁和鼠标版本控制混淆机制。我不知道是否有仅用版本控制的数据库（若是你知道请告诉我）。[2015-08-20更新]一名读者告诉我：

Firebird 和 Interbase 用不带锁的版本控制。版本控制对索引的影响挺有趣的：有时唯一索引会泛起重复，索引的条目会多于表行数，等等。若是你读过差别级此外隔离那部门内容，你会知道，提高隔离级别就会增添锁的数目和事务等候加锁的时间。这就是为什么多数数据库默认不会使用最高级此外隔离（即串行化）。固然，你总是可以自己去主流数据库（像MySQL, PostgreSQL 或 Oracle）的文档里查一下。日志治理器我们已经知道，为了提升性能，数据库把数据生存在内存缓冲区内。但若是当事务提交时服务器瓦解，瓦解时还在内存里的数据会丢失，这破损了事务的持久性。你可以把所有数据都写在磁盘上，可是若是服务器瓦解，最终数据可能只有部门写入磁盘，这破损了事务的原子性。事务作出的任何修改必须是或者打消，或者完成。有 2 个措施解决这个问题：

• 影子副本/页（Shadow copies/pages）：每个事务建立自己的数据库副本（或部门数据库的副本），并基于这个副原来事情。一旦堕落，这个副本就被移除；一旦乐成，数据库立刻使用文件系统的一个花招，把副本替换到数据中，然后删掉『旧』数据。
• 事务日志（Transaction log）：事务日志是一个存储空间，在每次写盘之前，数据库在事务日志中写入一些信息，这样当事务瓦解或回滚，数据库知道怎样移除或完成尚未完成的事务。

WAL（预写式日志）

影子副本/页在运行较多事务的大型数据库时制造了大量磁盘开销，以是现代数据库使用事务日志。事务日志必须生存在稳固的存储上，我不会深挖存储手艺，但至少RAID磁盘是必须的，以防磁盘故障。多数数据库（至少是Oracle, SQL Server, DB2, PostgreSQL, MySQL 和 SQLite) 使用预写日志协议（Write-Ahead Logging protocol ，WAL）来处置惩罚事务日志。WAL协议有 3 个规则：

• 1) 每个对数据库的修改都发生一条日志记载，在数据写入磁盘之前日志记载必须写入事务日志。
• 2) 日志记载必须按顺序写入；记载 A 发生在记载 B 之前，则 A 必须写在 B 之前。
• 3) 当一个事务提交时，在事务乐成之前，提交顺序必须写入到事务日志。

这个事情由日志治理器完成。简朴的明白就是，日志治理器处于缓存治理器（cache manager）和数据会见治理器（data access manager，卖力把数据写入磁盘）之间，每个 update / delete / create / commit / rollback 操作在写入磁盘之前先写入事务日志。简朴，对吧？回覆错误！ 我们研究了这么多内容，现在你应该知道与数据库相关的每一件事都带着『数据库效应』的诅咒。好吧，我们说正经的，问题在于，怎样找到写日志的同时保持优秀的性能的要领。若是事务日志写得太慢，整体都市慢下来。ARIES1992年，IBM 研究职员『发现』了WAL的增强版，叫 ARIES。ARIES 或多或少地在现代数据库中使用，逻辑未必相同，但AIRES背后的观点无处不在。我给发现加了引号是由于，根据MIT这门课的说法，IBM 的研究职员『仅仅是写了事务恢复的最佳实践要领』。AIRES 论文揭晓的时间我才 5 岁，我不体贴那些酸溜溜的科研职员老掉牙的闲言碎语。事实上，我提及这个典故，是在最先探讨最后一个手艺点前让你轻松一下。我阅读过这篇 ARIES 论文 的大量篇幅，发现它很有趣。在这一部门我只是简要的谈一下 ARIES，不外我强烈建议，若是你想相识真正的知识，就去读那篇论文。ARIES 代表『数据库恢回复型算法』（Algorithms for Recovery and Isolation Exploiting Semantics）。这个手艺要到达一个双重目的：

• 1) 写日志的同时保持优秀性能
• 2) 快速和可靠的数据恢复

有多个缘故原由让数据库不得不回滚事务：

• 由于用户作废
• 由于服务器或网络故障
• 由于事务破损了数据库完整性（好比一个列有唯一性约束而事务添加了重复值）
• 由于死锁

有时间（好比网络泛起故障），数据库可以恢复事务。这怎么可能呢？为了回覆这个问题，我们需要相识日志里生存的信息。

日志

事务的每一个操作（增/删/改）发生一条日志，由如下内容组成：

• LSN：一个唯一的日志序列号（Log Sequence Number）。LSN是定时间顺序分配的 * ，这意味着若是操作 A 先于操作 B，log A 的 LSN 要比 log B 的 LSN 小。
• TransID：发生操作的事务ID。
• PageID：被修改的数据在磁盘上的位置。磁盘数据的最小单元是页，以是数据的位置就是它所处页的位置。
• PrevLSN：统一个事务发生的上一条日志记载的链接。
• UNDO：作废本次操作的要领。
  好比，若是操作是一次更新，UNDO将或者生存元素更新前的值/状态（物理UNDO），或者回到原来状态的反向操作（逻辑UNDO） **。
• REDO：重复本次操作的要领。 同样的，有 2 种要领：或者生存操作后的元素值/状态，或者生存操作自己以便重复。
• …：（供您参考，一个 ARIES 日志另有 2 个字段：UndoNxtLSN 和 Type）。

进一步说，磁盘上每个页（生存数据的，不是生存日志的）都记载着最后一个修改该数据操作的LSN。*LSN的分配实在更庞大，由于它关系到日志存储的方式。但原理是相同的。** ARIES 只使用逻辑UNDO，由于处置惩罚物理UNDO太过杂乱了。注：据我所知，只有 PostgreSQL 没有使用UNDO，而是用一个垃圾接纳服务来删除旧版本的数据。这个跟 PostgreSQL 对数据版本控制的实现有关。为了更好的说明这一点，这有一个简朴的日志记载演示图，是由查询 “UPDATE FROM PERSON SET AGE = 18;” 发生的，我们假设这个查询是事务18执行的。【译者注： SQL 语句原文云云，应该是作者笔误 】每条日志都有一个唯一的LSN，链接在一起的日志属于统一个事务。日志根据时间顺序链接（链接列表的最后一条日志是最后一个操作发生的）。

日志缓冲区

为了防止写日志成为主要的瓶颈，数据库使用了日志缓冲区。当查询执行器要求做一次修改：

• 1) 缓存治理器将修改存入自己的缓冲区；
• 2) 日志治理器将相关的日志存入自己的缓冲区；
• 3) 到了这一步，查询执行器以为操作完成了（因此可以请求做另一次修改）；
• 4) 接着（不久以后）日志治理器把日志写入事务日志，什么时间写日志由某算法来决议。
• 5) 接着（不久以后）缓存治理器把修改写入磁盘，什么时间写盘由某算法来决议。

当事务提交，意味着事务每一个操作的 1 2 3 4 5 步骤都完成了。写事务日志是很快的，由于它只是『在事务日志某处增添一条日志』；而数据写盘就更庞大了，由于要用『能够快速读取的方式写入数据』。

STEAL 和 FORCE 计谋

出于性能方面的缘故原由，第 5 步有可能在提交之后完成，由于一旦发生瓦解，另有可能用REDO日志恢复事务。这叫做 NO-FORCE计谋。数据库可以选择FORCE计谋（好比第 5 步在提交之前必须完成）来降低恢复时的负载。另一个问题是，要选择数据是一步步的写入（STEAL计谋），照旧缓冲治理器需要等候提交下令来一次性所有写入（NO-STEAL计谋）。选择STEAL照旧NO-STEAL取决于你想要什么：快速写入可是从 UNDO 日志恢复缓慢，照旧快速恢复。总结一下这些计谋对恢复的影响：

• STEAL/NO-FORCE 需要 UNDO 和 REDO: 性能高，可是日志和恢复历程更庞大 (好比 ARIES)。多数数据库选择这个计谋。 注：这是我从多个学术论文和教程里看到的，但并没有看到官方文档里显式说明这一点。
• STEAL/ FORCE 只需要 UNDO.
• NO-STEAL/NO-FORCE 只需要 REDO.
• NO-STEAL/FORCE 什么也不需要: 性能最差，而且需要庞大的内存。

关于恢复

Ok，有了不错的日志，我们来用用它们！假设新来的实习生让数据库瓦解了（主要规则：永远是实习生的错。），你重启了数据库，恢复历程最先了。ARIES从瓦解中恢复有三个阶段：

• 1) 剖析阶段：恢复历程读取所有事务日志，来重修瓦解历程中所发生事情的时间线，决议哪个事务要回滚（所有未提交的事务都要回滚）、瓦解时哪些数据需要写盘。
• 2) Redo阶段：这一关从剖析中选中的一条日志记载最先，使用 REDO 来将数据库恢复到瓦解之前的状态。

在REDO阶段，REDO日志根据时间顺序处置惩罚（使用LSN）。对每一条日志，恢复历程需要读取包罗数据的磁盘页LSN。若是LSN（磁盘页）>= LSN（日志记载），说明数据已经在瓦解前写到磁盘（可是值已经被日志之后、瓦解之前的某个操作笼罩），以是不需要做什么。若是LSN（磁盘页）< LSN（日志记载），那么磁盘上的页将被更新。纵然将被回滚的事务，REDO也是要做的，由于这样简化了恢复历程（可是我信赖现代数据库不会这么做的）。

• 3) Undo阶段：这一阶段回滚所有瓦解时未完成的事务。回滚从每个事务的最后一条日志最先，而且根据时间倒序处置惩罚UNDO日志（使用日志记载的PrevLSN）。

 恢复历程中，事务日志必须注意恢复历程的操作，以便写入磁盘的数据与事务日志相一致。一个解决措施是移除被作废的事务发生的日志记载，可是这个太难题了。相反，ARIES在事务日志中记载赔偿日志，来逻辑上删除被作废的事务的日志记载。当事务被『手工』作废，或者被锁治理器作废（为了消除死锁），或仅仅由于网络故障而作废，那么剖析阶段就不需要了。对于哪些需要 REDO 哪些需要 UNDO 的信息在 2 个内存表中：

• 事务表（生存当前所有事务的状态）
• 脏页表（生存哪些数据需要写入磁盘）

当新的事务发生时，这两个表由缓存治理器和事务治理器更新。由于是在内存中，当数据库瓦解时它们也被破损掉了。剖析阶段的使命就是在瓦解之后，用事务日志中的信息重修上述的两个表。为了加速剖析阶段，ARIES提出了一个观点：检查点（check point），就是不时地把事务表和脏页表的内容，另有此时最后一条LSN写入磁盘。那么在剖析阶段当中，只需要剖析这个LSN之后的日志即可。

结语

写这篇文章之前，我知道这个问题有多大，也知道写这样一篇深入的文章会相当耗时。最后证实我过于乐观了，现实上花了两倍于预期的时间，可是我学到了许多。若是你想很好地相识数据库，我推荐这篇研究论文：《数据库系统架构》，对数据库有很好的先容（共110页），而且非盘算机专业人士也能读懂。这篇论文精彩的资助我制订了本文的写作企图，它没有像本文那样专注于数据结构和算法，更多的讲了架构方面的观点。若是你仔细阅读了本文，你现在应该相识一个数据库是何等的强盛了。鉴于文章很长，让我来提醒你我们都学到了什么：

• B+树索引概述
• 数据库的全局概述
• 基于成本的优化概述，特殊专注了联接运算
• 缓冲池治理概述
• 事务治理概述

可是，数据库包罗了更多的智慧巧技。好比，我并没有谈到下面这些棘手的问题：

• 怎样治理数据库集群和全局事务
• 怎样在数据库运行的时间发生快照
• 怎样高效地存储（和压缩）数据
• 怎样治理内存

以是，当你不得不在问题多多的 NoSQL数据库和坚如磐石的关系型数据库之间决议的时间，要三思而行。不要误会，某些 NoSQL数据库是很棒的，可是它们究竟还年轻，只是解决了少量应用关注的一些特定问题。最后说一句，若是有人问你数据库的原理是什么，你不用逃之夭夭，现在你可以回覆：或者，就让他/她来看本文吧。
上一篇 恋爱到底是性格相似好还是性格互补好？
下一篇 麓学堂 | 这个夏天，来麓湖做个“问题孩子”~