mysql日志中redo和undo日志概念以及应用
https://blog.csdn.net/q1060701529/article/details/102393291
ACID
首先来讨论事务的四大特性ACID
-
原子性（Atomicity）：事务作为一个整体来执行，要不都执行，要不都不执行
-
一致性（Consistency）：事务必须保证数据库从一个一致状态转移到另一个一致状态。不能破坏关系数据的完整性以及业务逻辑的一致性。完整性一般就是数据的域完整性、实体完整性以及参照完整性。域完整性始址我们在创建表的时候指定的数据类型，输入限制。实体完整性规定我们的记录必须唯一，也就是说一个记录中必须存在一个或者多个字段唯一标示这一条记录。参照完整性则一般对应于关系表之间的关系，保证主键和外键之间的参照关系。不能因为执行事务儿破坏数据的完整性。
逻辑业务一致性举个例子。再银行转账操作中，a、b初始值1000，a像b转100，但是不能因为我们的事务操作使得b只收到了50。事务要保证业务操作中我们的业务一致性不能乱。
-
隔离性（Isolation）：多个事务并发的时候，一个事务执行的时候不会影响另一个事务。
-
持久性（Durability）：已被提交的事务必须保存再数据库中。
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操作的特点总结如下：
- 在更新数据前把数据记录到undo操作
- 持久性，只要数据提交则必定保存到了数据库
- undo log必须先于数据持久化到磁盘，这样的话若数据写入磁盘或者进行commit是出错，可以根据undo日志进行回滚
- 若事务再undo持久化之前出错，则数据库中的数据还保持在事务之前的状态。undo日志中也没有相应的记录，不需要回滚
当然undo的缺陷也很明显，他需要提交一次undo日志到磁盘，和一次数据到磁盘。io次数过多，性能太低。
redo的出现
为了解决undo性能过低的问题，就引入了redo，redo与undo正相反，他记录的是新数据的备份。并且事务在提交的时候只需将redo日志持久化到磁盘即可，数据可以根据redo日志异步的持久到磁盘。当发生异常的时候，只要redo日志写入到磁盘我们就可以根据redo日志来进行回滚。倘若redo日志再持久化到磁盘的时候出错，数据库就相当于没有执行过当前事务。
数据库恢复策略
1.只按照redo日志进行回复，所有事务（包括未提交的事务）都按照redo日志，也就是视图提交后的结果进行恢复
2.第二种分两步走，第一部和第一种一样，先根据redo日志对所有事务进行恢复 操作。再根据undo日志对未提交的日志进行回复操作。
Mysql采用的是第二种恢复策略。显然第一种策略也能进行事无恢复，但是为什么Mysql会采用第二种呢。我个人理解是这样的，虽然只按照redo日志进行回复也能回复数据。但是redo日志记录的是事务修改后的数据，这对于已经提交的事务是没有问题的。但是对于未提交的事务，当灾难发生时，事务并没有被提交，逻辑上应该认为这个事务是操作失败的，也就是类似于在做普通的sql的时候出现了异常，此时我们需要做回滚操作。只按照redo日志进行恢复，那么那些未提交的事务会直接恢复到事务提交后的结果。
不妨设想一个场景，a向b转100块钱，这个事务执行的顺序也就是，将 a-100和b+100的结果写入到redo日志，redo日志进行持久化操作，最后一步就是事务提交。但是再事务提交的节骨眼儿上服务器宕了，这时候由于用户a长时间得不到服务器响应，客户端也应该向用户显示操作失败吧（假设需要同步的显示操作结果），但是根据redo日志进行回复后，a-100 以及 b+100的操作被数据库恢复了，但是用户那边的情况却恰恰相反。这样对于一个可靠性要求比较高的系统来说本就是灾难