MySQL系列： undo和redo工作原理

ACID

首先来讨论事务的四大特性ACID

• 原子性（Atomicity）：事务作为一个整体来执行，要不都执行，要不都不执行

• 一致性（Consistency）：事务必须保证数据库从一个一致状态转移到另一个一致状态。不能破坏关系数据的完整性以及业务逻辑的一致性。

  完整性一般就是数据的域完整性、实体完整性以及参照完整性。域完整性始址我们在创建表的时候指定的数据类型，输入限制。实体完整性规定我们的记录必须唯一，也就是说一个记录中必须存在一个或者多个字段唯一标示这一条记录。参照完整性则一般对应于关系表之间的关系，保证主键和外键之间的参照关系。不能因为执行事务儿破坏数据的完整性。

  逻辑业务一致性举个例子。再银行转账操作中，a、b初始值1000，a像b转100，但是不能因为我们的事务操作使得b只收到了50。事务要保证业务操作中我们的业务一致性不能乱。

• 隔离性（Isolation）：多个事务并发的时候，一个事务执行的时候不会影响另一个事务。

• 持久性（Durability）：已被提交的事务必须保存再数据库中。

 

Undo(历史数据，提交前持久化，修改前写入，保证原子性)

undo日志到底做了什么

undo日志会记录事务执行过程中，每次修改的数据的原始值。

x =5,y  = 8
t1 begin:
	//undo日志记录x=5
	x = x- 1;
	//undo日志记录y=8
	y = y-2;
	//事务执行临近结束，将undo日志写入到磁盘
	//将数据写入到磁盘
commit

我们都知道，事务是具有原子性的要不全做，要不全部做。可到底是什么机制协助了数据库

undo日志就可以保证数据库事务操作的原子性，从上面的流程我们可以得知每次进行事务修改之前，都会吧未修改之前的值存储到undo日志中，当然再提交的时候也是先将undo写到磁盘，再把修改后的数据写到磁盘。倘若再undo写入磁盘之前发生了异常，根本就不需要做任何操作，这时候事务是被认为执行失败的，也不需要回滚，因为undo日志没有写入磁盘，数据库被认为处于没有执行事务的状态。若再数据写入磁盘的时候发生故障，则可以根据undo日志进行回滚。

整个过程下来起码实现了原子性以及持久性

undo操作的特点总结如下：

1. 在更新数据前把数据记录到undo操作
2. 持久性，只要数据提交则必定保存到了数据库
3. undo log必须先于数据持久化到磁盘，这样的话若数据写入磁盘或者进行commit是出错，可以根据undo日志进行回滚
4. 若事务再undo持久化之前出错，则数据库中的数据还保持在事务之前的状态。undo日志中也没有相应的记录，不需要回滚

当然undo的缺陷也很明显，他需要提交一次undo日志到磁盘，和一次数据到磁盘。io次数过多，性能太低。

Redo（新数据，提交前持久化，修改后写入，保证持久性）

redo的出现

为了解决undo性能过低的问题，就引入了redo

redo与undo正相反，他记录的是新数据的备份。并且事务在提交的时候只需将redo日志持久化到磁盘即可，数据可以根据redo日志异步的持久到磁盘。当发生异常的时候，只要redo