MySQL的事务日志

日志保证特性

事务的隔离性是由锁机制来保证
而事务的持久性有redo log保证
事务的原子性，一致性有undo log来保证

redo log

redo log由两部分组成 redo log buffer，redo log file
一方面，缓冲池帮助我们消除CPU和磁盘之间的鸿沟，checkpoint机制可以保证数据的最终落盘，然而由于checkpoint并不是每次变更的时候触发，而是master线程隔一段时间去处理，所以最坏的情况就是事务提交之后，刚写完缓冲池，数据库宕机了，那么这段数据就是丢失的，无法恢复

另一方面，redo log file可以保证事务的持久性

好处

redo log降低了刷盘的频率
redo log占用的磁盘空间很小

特点

redolog是顺序写入磁盘的
事务执行的过程中，redo log不断记录

redo的整体流程

1.先将原始的数据从磁盘中读入内存中，修改内存数据拷贝
2.生成一条重做日志并写入redo log buffer，记录的是数据被修改之后的值
3.当事务commit时，将redo log buffer中的内容刷新到redo log file，对redo log file采用追加的方式
4.定期将内存中修改的数据刷新到磁盘当中

Write-Ahead Log(预先日志持久化)：在持久化一个数据页之前，先将内存中相应的日志页持久化

redo log的刷盘策略

+

Undo Log

作用

回滚数据
MVCC

undo log的存储结构

1.回滚段与undo页

innodb对undo log的管理采用段的方式，也就是回滚段，每个回滚段记录了1024个undo log segment，而在每个undo log segment段中进行undo 页的申请

2.回滚段与事物

1..每个事物只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事物
2.当一个事物开始时，会制定一个回滚段，在事物进行的过程中，数据被修改，原始的数据就会被复制到回滚段
3.在回滚段中，事务会不断填充盘区，直至事务结束或者所有空间被用完，如果当前的盘区还不够用，事务会在段中请求扩展下一个盘区；如果所有已分配的盘区都被用完，事务会覆盖最初的盘区或者在回滚段允许的情况下扩展新的盘区使用
4.回滚段存在于undo表空间中，在数据库中可以存在多个undo表空间，但同一时刻只能使用一个undo表空间
5.当事务提交时，innodb存储引擎会做以下两件事情
1.将undolog放入列表，以供后续的purge操作
2.判断undo log所在的页是否可以重用，如可以分配给下个事务使用

3.回滚段中数据分类

1.未提交的回滚数据
2.已提交但未过期的回滚数据
3.事务已经提交并过期的数据

undo的类型

innodb引擎中分类
insert undo log
update undo log

undo log 生命周期

undo log的删除

小结

两阶段提交

https://cloud.tencent.com/developer/article/1790507