MySQL事务中的redo与undo的剖析（图文）
我们都晓得事务有4种特性：原子性、一致性、隔离性和耐久性，在事务中的操纵，要末全部施行，要末全部不做，这就是事务的目的。事务的隔离性由锁机制实现，原子性、一致性和耐久性由事务的redo 日志和undo 日志来保障。所以本篇文章将计议对于事务中的redo和undo的几个题目：
redo 日志与undo日志离别有哪些？
redo 怎样保障事务的耐久性？
undo log 可否是redo log的逆历程？
redo log
Redo 的类型
重做日志(redo log)用来保障事务的耐久性，即事务ACID中的D。现实上它可以分为下列两品种型：
物理Redo日志
逻辑Redo日志
在InnoDB存储引擎中，大局部状况下 Redo是物理日志，记载的是数据页的物理变化。而逻辑Redo日志，不是记载页面的现实修改，而是记载修改页面的一类操纵，比方创建数据页时，需要记载逻辑日志。对于逻辑Redo日志波及更加底层的内容，这里我们只需要记住绝大数状况下，Redo是物理日志即可，DML对页的修改操纵，均需要记载Redo.
Redo 的作用
Redo log的主要作用是用于数据库的解体恢复
Redo 的组成
Redo log可以简略分为下列两个局部：
一是内存中重做日志缓冲 (redo log buffer),是易失的，在内存中
二是重做日志文件 (redo log file)，是耐久的，保留在磁盘中
什么时候写Redo?
上面那张图简略地表现了Redo的写入流程，这里再细说下写入Redo的机会：
在数据页修改完成之后，在脏页刷出磁盘以前，写入redo日志。注意的是先修改数据，后写日志
redo日志比数据页先写回磁盘
汇集索引、二级索引、undo页面的修改，均需要记载Redo日志。
Redo的整体流程
下面以一个更新事务为例，宏不雅上掌握redo log 流转历程，如下图所示：
上图表示了重做日志的写入流程，每个mini-transaction对应每一条DML操纵，比方一条update语句，其由一个mini-transaction来保障，对数据修改后，发生redo1，第一将其写入mini-transaction私有的Buffer中，update语句完毕后，将redo1从私有Buffer拷贝到公有的Log Buffer中。当整个外部事务提交时，将redo log buffer再刷入到redo log file中。
undo log
undo log的定义
undo log主要记载的是数据的逻辑变化，为了在产生差错时回滚以前的操纵，需要将以前的操纵都记载下来，然后在产生差错时才可以回滚。
undo log的作用
undo是一种逻辑日志，有两个作用：
用于事务的回滚
MVCC
对于MVCC(多版本并发控制)的内容这里就未几说了，本文重点关注undo log用于事务的回滚。
undo日志，只将数据库逻辑地恢复到本来的模样，在回滚的时候，它现实上是做的相反的工作，比方一条INSERT ，对应一条 DELETE，关于每个UPDATE,对应一条相反的 UPDATE,将修改前的行放回去。undo日志用于事务的回滚操纵进而保证了事务的原子性。
undo log的写入机会
DML操纵修改聚簇索引前，记载undo日志
二级索引记载的修改，不记载undo日志
需要注意的是，undo页面的修改，一样需要记载redo日志。
undo的存储位置
在InnoDB存储引擎中，undo存储在回滚段(Rollback Segment)中,每个回滚段记载了1024个undo log segment，而在每个undo log segment段中进行undo 页的申请，在5.6之前，Rollback Segment是在同享表空间里的，5.6.3之后，可通过 innodb_undo_tablespace设定undo存储的位置。
undo的类型
在InnoDB存储引擎中，undo log分为：
insert undo log
update undo log
insert undo log是指在insert 操纵中发生的undo log，由于insert操纵的记载，只对事务自身可见，对其他事务不成见。故该undo log可以在事务提交后直接删除，不需要进行purge操纵。
而update undo log记载的是对delete 和update操纵发生的undo log，该undo log可能需要供给MVCC机制，因而不克不及再事务提交时就进行删除。提交时放入undo log链表，期待purge线程进行最后的删除。
增补：purge线程两个主要作用是：清算undo页和革除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操纵现实上并不是真正的删除掉数据行，而是一种Delete Mark操纵，在记载上标识Delete_Bit，而不删除记载。是一种"假删除",只是做了个标志，真正的删除工作需要后台purge线程去完成。
undo log 可否是redo log的逆历程？
undo log 可否是redo log的逆历程？其实从前文就可以得出答案了，undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到本来的模样，而redo log是物理日志，记载的是数据页的物理变化，显然undo log不是redo log的逆历程。
redo & undo总结
下面是redo log + undo log的简化历程，便于了解两种日志的历程：
假如有A、B两个数据，值离别为1,2. 1. 事务开端 2. 记载A=1到undo log 3. 修改A=3 4. 记载A=3到 redo log 5. 记载B=2到 undo log 6. 修改B=4 7. 记载B=4到redo log 8. 将redo log写入磁盘 9. 事务提交
现实上，在insert/update/delete操纵中，redo和undo离别记载的内容都不同，量也不同。在InnoDB内存中，个别的次序如下：
写undo的redo
写undo
修改数据页
写Redo
小结
本文剖析了事务中的redo和undo日志，参照 了一些材料书籍整理得出，可能有些地方表述的不分明。若有不合错误之处，欢送指出。
以上就是MySQL事务中的redo与undo的剖析（图文）的细致内容，更多请关注 百分百源码网 其它相干文章！
