目录
事务有4种特性：原子性、一致性、隔离性和持久性。那么事务的四种特性到底是基于什么机制实现呢？
事务的隔离性由
锁机制实现。而事务的原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。
REDO LOG 称为
重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。UNDO LOG 称为
回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。有的DBA或许会认为 UNDO 是 REDO 的逆过程，其实不然。其实不然。REDO和UNDO都可以视为是一种
恢厦操作
redo log:是存储引擎层(innodb)生成的日志，记录的是"
物理级别"上的页修改操作，比如页号xx、偏移量ywy写入了'zzz'数据。主要为了保证数据的可靠性;提交，由redo log来保证事务的持久化。
undo log:是存储引擎层(innodb)生成的日志，记录的是
逻辑操作日志，比如对某一行数据进行了INSERT语句操作，那么undo log就记录一条与之相反的DELETE操作。主要用于事务的回滚(undo log 记录的是每个修改操作的逆操作)和一致性非锁定读(undo log回滚行记录到某种特定的版本---MVCC，即多版本并发控制)。
一、redo日志
InnoDB存储引擎是以页为单位来管理存储空间的。在真正访问页面之前需要把在磁盘上的页缓存到内存中的 Buffer Pool之后才可以访问。所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷入磁盘（ checkPoint机制），通过缓冲池来优化CPU和磁盘之间的鸿沟，这样就可以保证整体的性能不会下降太快。
1、为什么需要REDO日志
2、REDO日志的好处、特点
1. 好处
redo日志降低了刷盘频率
redo日志占用的空间非常小
存储表空间ID、页号、偏移量以及需要更新的值，所需的存储空间是很小的，刷盘快。2. 特点
redo日志是顺序写入磁盘的
在执行事务的过程中，每执行一条语句，就可能产生若干条redo日志，这些日志是按照产生的
顺序写入磁盘的，也就是使用顺序Io，效率比随机Io快。事务执行过程中，redo log不断记录
redo log跟bin log的区别，redo log是
存储引擎层产生的，而bin log是数据阵层广生的。假设一个事务，对表做10万行的记录插入，在这个过程中，一直不断的往redo log顺序记录，而bin log不会记录，直到这个事务提交，才会一次写入到bin log文件中。
3、redo的组成
Redo log可以简单分为以下两个部分：
- 重做日志的缓冲 (redo log buffer) ，保存在内存中，是易失的。
- 重做日志文件 (redo log file) ，保存在硬盘中，是持久的。
4、redo的整体流程
以一个更新事务为例，redo log 流转过程，如下图所示：
第1步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
第2步：生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值
第3步：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加写的方式
第4步：定期将内存中修改的数据刷新到磁盘中
体会：Write-Ahead Log(预先日志持久化)：在持久化一个数据页之前，先将内存中相应的日志页持久化。
5、redo log的刷盘策略
6、不同刷盘策略演示
流程图
小结: innodb_flush_log_at_trx_commit=1
为1时，只要事务提交成功,redo log记录就一定在硬盘里，不会有任何数据丢失。
如果事务执行期间MySQL挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。可以保证ACID的D，数据绝对不会丢失，但是效率最差的。
建议使用默认值，虽然操作系统宕机的概率理论小于数据库宕机的概率，但是一般既然使用了事务，那么数据的安全相对来说更重要些。
小结: innodb_flush_log_at_trx_commit=2
为2时，只要事务提交成功,
redo log buffer中的内容只写入文件系统缓存（ page cache ) 。如果仅仅只是
MySQL挂了不会有任何数据丢失，但是操作系统宕机可能会有1秒数据的丢失，这种情况下无法满足ACID中的D。但是数值2肯定是效率最高的。
7、写入redo log buffer 过程
1.补充概念：Mini-Transaction
2. redo 日志写入log buffer
3.redo log block的结构图
8、redo log file
1.相关参数设置
2.日志文件组
3.checkpoint
9、redo log小结
相信大家都知道redo log的作用和它的刷盘时机、存储形式:
InnoDB的更新操作采用的是Write Ahead Log(预先日志持久化)策略，即先写日志，再写入磁盘
二、 Undo日志
redo log是事务持久性的保证，undo log是事务原子性的保证。在事务中 更新数据 的 前置操作 其实是要 先写入一个 undo log 。
1、如何理解Undo日志
事务需要保证 原子性 ，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半
会出现一些情况，比如：
- 情况一：事务执行过程中可能遇到各种错误，比如 服务器本身的错误 ， 操作系统错误 ，甚至是突然 断电 导致的错误。
- 情况二：程序员可以在事务执行过程中手动输入 ROLLBACK 语句结束当前事务的执行。
以上情况出现，我们需要把数据改回原先的样子，这个过程称之为 回滚 ，这样就可以造成一个假象：这个事务看起来什么都没做，所以符合 原子性 要求。
2、Undo日志的作用
作用1：回滚数据
用户对undo日志可能
有误解: undo用于将数据库物理地恢复到执行语句或事务之前的样子。但事实并非如此。undo是逻辑日志，因此只是将数据库逻辑地恢复到原来的样子。所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能大不相同。这是因为在多用户并发系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要任务就是协调对数据记录的并发访问。比如，一个事务在修改当前一个页中某几条记录，同时还有别的事务在对同一个页中另几条记录进行修改。因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行的工作。
作用2：MVCC
undo的另一个作用是MVCC，即在InnoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。
3、 undo的存储结构
1. 回滚段与undo页
2. 回滚段与事务
3. 回滚段中的数据分类
4、undo的类型
在InnoDB存储引擎中，undo log分为：
insert undo log
insert undo log是指在insert操作中产生的undo log。因为insert操作的记录，只对事务本身可见，对其他事务不可见(这是事务隔离性的要求)，故该undo log可以在事务提交后直接删除。不需要进行purge操作。
update undo log
update undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。
5、undo log的生命周期
1. 简要生成过程
只有Buffer Pool的流程：
有了Redo Log和Undo Log之后：
2. 详细生成过程
3.undo log是如何回滚的
以上面的例子来说，假设执行rollback，那么对应的流程应该是这样：
1. 通过undo no=3的日志把id=2的数据删除
2. 通过undo no=2的日志把id=1的数据的deletemark还原成0
3. 通过undo no=1的日志把id=1的数据的name还原成Tom
4. 通过undo no=0的日志把id=1的数据删除
4.undo log的删除
针对于insert undo log
因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。
针对于update undo log
该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。
补充:
purge线程两个主要作用是:
清理undo页和清除page里面带有Delete_Bit标识的数据行。是InnoDB中，事分中的Delete操作实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识Delete_Bit，而 不删除记录。是一种"假删除"只是做了个标记，真正的删除工作需要后台purge线程去完成。
6、小结
undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。
redo log是物理日志，记录的是数据页的物理变化，undo log不是redo log的逆过程。
高级篇笔记PDF自取
链接：https://pan.baidu.com/s/1pVqrTwIZFoED77i-EFmw6g?pwd=3333
提取码：3333
764
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
