undo log保证事务的原子性（回滚）

A、Begin

B、记录A=1到undo log中

C、修改记录A=3

D、记录B=1到undo log中

E、修改记录B=2

F、写入undo log到磁盘中

G、写入数据到磁盘中

H、Commit

A-E步骤都是在内存中完成

A-F之间如果出现问题，由于undo log和数据都未写入磁盘，所以直接回滚

F之后出现问题，由于undo log已经落盘，可以利用undo log回滚

如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化，即Redo Log.

PS:这里有一个隐含的前提条件：数据都是先读到内存中，然后修改内存中的数据，最后将数据写回磁盘。

redo log(优化持久化性能)

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

A、Begin

B、记录A=1到undo log中

C、修改记录A=3

D、记录修改日志到redo log中

E、记录B=1到undo log中

F、修改记录B=2

G、记录修改日志到redo log中

H、将redo log写入磁盘

I、Commit

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

为了保证Redo Log能够有比较好的IO性能，InnoDB 的 Redo Log的设计有以下几个特点：

A. 尽量保持Redo Log存储在一段连续的空间上。因此在系统第一次启动时就会将日志文件的空间完全分配。以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。
B. 批量写入日志。日志并不是直接写入文件，而是先写入redo log buffer.当需要将日志刷新到磁盘时 (如事务提交),将许多日志一起写入磁盘.
C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起，以减少日志占用的空间。例如,Redo Log中的记录内容可能是这样的：

记录1: <trx1, insert …>
记录2: <trx2, update …>
记录3: <trx1, delete …>
记录4: <trx3, update …>
记录5: <trx2, insert …>

D. 因为C的原因,当一个事务将Redo Log写入磁盘时，也会将其他未提交的事务的日志写入磁盘。 E. Redo Log上只进行顺序追加的操作，当一个事务需要回滚时，它的Redo Log记录也不会从Redo Log中删除掉。