mysql 事务日志 redo log和undo log

https://blog.csdn.net/caoxiaohong1005/article/details/83022858

1 MySql宕机时正在处理的事务会如何？

针对突然宕机的问题：MySql不会自动继续执行，不会自动直接回滚，但是可以人工手动选择继续执行或者直接回滚，依据是事务日志。

事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是人们口中常说的“日志先行”(Write-Ahead Logging)

2 日志分为2种

1. redo log
   保障的是事务的持久性和一致性

   在系统启动的时候，就已经为redo log分配了一块连续的存储空间，以顺序追加的方式记录redo log，通过顺序io来改善性能

   所有的事务共享redo log的存储空间，它们的redo log按语句的执行顺序，依次交替的记录在一起

   如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。

2. undo log
   保障了事务的原子性，主要为事务的回滚服务

   undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作

3 redo log和undo log的过程分析

    eg : 假设有2个数值，分别为A和B，值为1，2
    1 start transaction;
    2 记录 A=1 到undo log;
    3 update A = 3；
    4 记录 A=3 到redo log；
    5 记录 B=2 到undo log；
    6 update B = 4；
    7 记录B = 4 到redo log；
    8 将redo log刷新到磁盘
    9 commit

在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响.

如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化

若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘