【MySQL】事务日志

事务的隔离性由锁机制实现，事务的原子性、一致性和持久性由redo日志和undo日志实现。

一、redo日志

1.1、为什么需要redo日志

一方面，由于数据从内存写回磁盘需要一定的时间，假如在事务提交后，还没有写回磁盘，数据库就宕机的话，那么这段数据就无法恢复了。
另一方面，为了维持事务的持久性。对于一个已经提交的事务，即使提交后系统崩溃，也要保证这个事务对数据库中所做的更改也不能丢失。
保证持久性的方法：

在事务提交完成前把该事务所修改的所有页面都刷新到磁盘，虽然方法简单，但是修改量与刷新磁盘的工作量严重不成正比，仅仅为了修改一个字节的数据可能就要刷新一页的数据在磁盘上。并且由于页面可能并不相邻，使用到的随机IO刷新较慢。
另一种解决思路是把修改的东西记录一下。比如记录在第0号表的10号页面的偏移量为100处的值更新为2。
redo日志就采用了WAL技术（Write-Ahead Logging），这种技术的思想是先写日志、再写磁盘，日志写入成功就算提交成功。当发生宕机时，就可以通过redo日志来恢复。

1.2、redo日志的好处

好处

1、redo日志降低了磁盘刷新频率
2、redo日志占用的空间非常小

特点

redo日志顺序写入磁盘
事务执行过程中，redo日志不断记录。

1.3、redo组成

重做日志的缓冲
在数据库服务器启动时向系统申请了一大片称为redo log buffer的连续空间。这片空间被划分为若干个redo log block。
在这里插入图片描述

1.4、redo更新流程

在这里插入图片描述
1、将数据从磁盘读到内存中
2、生成redo日志并写入redo log buffer
3、当事务commit后，将redo log buffer中的内容刷新到redo log file中。
4、定期将内存中修改的数据刷新到磁盘中。

1.5、redo log刷盘策略

1.6、redo log file

日志文件组
在这里插入图片描述
总共的redo日志文件大小为innode_log_file_size * innode_log_files_in_ group 。采用这种循环的方式向redo日志文件组中写入数据，会导致后写入的数据覆盖掉前面的数据。

check point
这个日志文件组有两个重要的属性：

write pos是当前位置，一边写一边后移
checkpoint是当前要擦除的位置，也是后移。

结构类似于循环队列:

在这里插入图片描述

二、undo日志

redo日志保证了事务的持久性，undo日志保证了事务的原子性

2.1、undo日志的理解

每当我们对一条记录进行改动时，都需要把回滚的东西记录下来。比如：

对于每个INSERT，InnoDB引擎就会完成一个DELETE
对于每个DELETE，InnoDB引擎就会完成一个INSERT
对于每个UPDATE，InnoDB引擎就会完成一个相反的UPDATE

这些为了回滚而记录的内容称为回滚日志（undo log）。此外，undo log也会产生redo log来保证持久性。

2.2、undo日志作用

回滚数据
undo日志只是将数据库逻辑的恢复，但是数据在物理磁盘上的存储可能不太一样。
MVCC
多版本并发控制

2.3、undo存储结构

2.3.1、回滚段与undo页

回滚段：InnoDB对undo log的管理采用段的方式
undo页：每个回滚段记录了1024个undo log segment，在每个undo log segment中进行undo页的申请。
undo页的重用：如果为每个事务分配一个页（一页默认16K），且每秒处理1000个事务，那么每秒就需要16K*1000=16M的空间，运行时间长了就会导致磁盘空间的浪费。
重用表示多个事务共用一页，如果事务提交后，则不会立即删除undo页，而是被挂到链表中，对其已使用空间进行判断。