MySQL Redo Undo MVCC

1、undo保证事务的原子性（回滚）

A、Begin

B、记录A=1到undo log中

C、修改记录A=3

D、记录B=1到undo log中

E、修改记录B=2

F、写入undo log到磁盘中

G、写入数据到磁盘中

H、Commit

A-E步骤都是在内存中完成

A-F之间如果出现问题，由于undo log和数据都未写入磁盘，所以直接回滚

F之后出现问题，由于undo log已经落盘，可以利用undo log回滚

缺点：

每次数据库的修改都必须将数据以同步的方式写入磁盘

数据写入磁盘属于随机IO，性能方面较差

2、undo+redo

A、Begin

B、记录A=1到undo log中

C、修改记录A=3

D、记录修改日志到redo log中

E、记录B=1到undo log中

F、修改记录B=2

G、记录修改日志到redo log中

H、将redo log写入磁盘

I、Commit

不需要实时以同步的方式将数据写入磁盘，数据可以后台异步写入磁盘

redo log写入磁盘是顺序IO 

undo log也写入到redo log中

redo 缓存刷盘规则：

事务提交时

当log buffer 中一半的内存空间已经被使用时

log checkpoint时

3、check point

check point机制是为了减少实例恢复的时间

缓冲池不够用时，触发checkpoint，将脏页刷盘

重做日志不够用时，刷新磁盘

刷脏页的时候不会阻塞，但是期间修改数据的操作的页也会记录LSN，恢复时将与redo中的LSN进行比较判断，避免了重复操作

4、LSN（日志序列号）

代表着重做日志的写入总量，写入redo多少，就单调递增多少

同时也代表着checkpoint的位置

还代表着页的版本（数据页上面也有LSN号，通过与redo的LSN比较决定是否需要进行数据恢复）

5、实例恢复

     

commit到commit ok之间（prepare阶段）需要先写binlog（主从），否则有可能因为binlog写失败影响主从

先恢复已提交完成事务——>未commit事务进行回滚——>对于prepare（已commit未OK）事务，如果已经写binlog则提交，否则回滚

6、MVCC

解决读写间阻塞的问题