mysql批量造数据_MySQL解密：InnoDB存储引擎重做日志漫游

撤消日志

Undo Log是为了实现事务的原子性。 在MySQL数据库存储引擎中，Undo Log也用于实现多版本并发控制（简称MVCC）。

事务原子性()

事务中的所有操作必须完成或者不执行任何操作，并且只有部分操作不能执行。 如果执行过程中出现错误，则()到事务开始之前的状态，就好像事务从未执行过一样。

原理：Undo Log的原理非常简单。 为了满足事务的原子性，在操作任何数据之前，首先必须将数据备份到一个地方（这个存储数据备份的地方称为Undo Log）。 然后修改数据。 如果发生错误或者用户执行语句，系统可以使用Undo Log中的备份将数据恢复到事务开始之前的状态。

Undo Log除了保证事务的原子性之外，还可以用来辅助完成事务的持久化。

交易持久性()

一旦事务完成，该事务对数据库所做的所有修改都会持久化到数据库中。 为了保证持久性，数据库系统会将修改的数据完整记录到持久化存储中。 使用Undo Log实现事务的原子性和持久化的简化流程，假设有两个数据A和B，值分别为1和2。

A. 交易开始。

B. 将A=1记录到undo日志中。

C、修改A=3。

D. 将B=2记录到撤消日志中。

E、修改B=4。

F. 将撤消日志写入磁盘。

G. 将数据写入磁盘。

H. 交易提交

这里有一个隐含的前提条件：‘数据先读入内存，然后修改内存中的数据，最后将数据写回磁盘’。 之所以能够同时保证原子性和持久性，是因为有以下特点： A、更新数据前记录Undo log。

B. 为了保证持久性，必须在事务提交之前将数据写入磁盘。 只要事务成功提交，数据就一定已经被持久化了。

C. 撤消日志必须先于数据持久化到磁盘。 如果系统在G和H之间崩溃，那么undo log是完整的，可以用来回滚事务。

D.如果由于数据没有持久化到磁盘而在AF之间系统崩溃。 因此，磁盘上的数据仍然保持在事务开始之前的状态。

缺点：数据和Undo Log在每个事务提交之前写入磁盘，这会导致大量的磁盘IO，从而导致性能低下。 如果能够将数据缓存一段时间，就可以减少IO，提高性能。 但这会失去交易的持久性。 因此，引入了另一种机制来实现持久化，即Redo Log。

重做日志

原理与Undo Log相反。 Redo Log记录新数据的备份。 事务提交前，只需要持久化Redo Log，不需要持久化数据。 当系统崩溃时，虽然数据没有被持久化，但是Redo Log已经被持久化了。 系统可以根据Redo Log的内容将所有数据恢复到最新状态。

撤消+重做事务的简化流程

假设有两个数据A和B，其值分别为1和2。

A. 交易开始。

B. 将A=1记录到undo日志中。

C、修改A=3。

D. 将A=3记录到重做日志中。

E.记录B=2到撤销日志。

F、修改B=4。

G. 将B=4记录到重做日志中。

H. 将重做日志写入磁盘。

一、交易提交

撤消+重做事务的特点

A.为了保证持久性，在事务提交之前必须持久化Redo Log。 B、事务提交前数据不需要写入磁盘，而是缓存在内存中。 C.重做日志保证事务的持久性。 D、Undo Log保证事务的原子性。 E. 有一个隐含的特性，数据必须晚于重做日志写入持久存储。

IO性能

Undo + Redo的设计主要考虑提高IO性能。 虽然通过缓存数据减少了写数据的IO，但是引入了一种新的IO，即写Redo Log的IO。 如果Redo Log的IO性能不好，就无法达到提高性能的目的。

A、为了保证Redo Log能够有更好的IO性能，Redo Log的设计有以下特点： 尽量让Redo Log存储在连续的空间中。 因此，当系统第一次启动时，日志文件的空间将被完全分配。 以顺序追加的方式记录Redo Log，通过顺序IO提高性能。

B、批量写入日志。 日志不是直接写入文件，而是先写入重做日志。 当日志需要刷新到磁盘时（比如事务提交），很多日志会一起写入磁盘。

C、并发事务共享Redo Log的存储空间，其Redo Log按照语句的执行顺序交替记录在一起，以减少日志占用的空间。 例如，Redo Log中的记录内容可能是这样的：

记录1：

记录2：

记录3：

记录4：

记录5：

D、因为C，当一个事务将Redo Log写入磁盘时，其他未提交事务的日志也会写入磁盘。

E. 仅对重做日志执行顺序追加操作。 当事务需要回滚时，其Redo Log记录不会从Redo Log中删除。

- 恢复（）

恢复策略

前面提到，未提交的事务和回滚的事务也会记录在Redo Log中。 因此，在恢复过程中，这些事务必须经过特殊处理。 有 2 种不同的恢复策略： A. 恢复时，仅记录重做日志。 执行已提交的交易。 B. 恢复时，重做所有事务，包括未提交的事务和回滚的事务。 然后通过Undo Log回滚那些未提交的事务。

存储引擎恢复机制

MySQL数据库存储引擎采用策略B。存储引擎中的恢复机制有几个特点： A.重做Redo Log时，不关心事务性。 恢复时，没有BEGIN，也没有任何行为。 每个日志属于哪个事务并不重要。 虽然Redo Log中会记录事务ID等与事务相关的内容，但这些内容仅被视为要操作的数据的一部分。

B、使用策略B时，必须要持久化Undo Log，在写入Redo Log之前，必须先将对应的Undo Log写入磁盘。 撤消和重做日志之间的这种关系使持久性变得复杂。 为了降低复杂度，Undo Log被视为数据，因此记录Undo Log的操作也会记录在redo log中。 这样，undo log就可以像数据一样被缓存起来，而不必先于redo log写入磁盘。

包含撤消日志操作的重做日志如下所示：

记录1：>

记录3：>

记录4：

记录5：>

记录6：

C. 至此，还有一个问题尚不清楚。 既然Redo不是事务性的，那不是可以重新执行回滚的事务吗？

它的确是。 同时，事务回滚时的操作也会记录在重做日志中。 回滚操作本质上是对数据的修改，因此回滚期间的数据操作也会记录在Redo Log中。 回滚事务的重做日志如下所示：

记录1：>

记录2：

记录3：>

记录4：

记录5：>

记录6：

记录7：

记录8：

记录9：

回滚事务的恢复操作是先重做，后撤消，因此不会破坏数据的一致性。

存储引擎中的相关函数