在更新数据库的SQL语句执行过程中，会用到 redo log 和 binlog 两个日志模块。

流程如下：

分析器 -> 权限校验 -> 执行器 -> 引擎 redo log(prepare 状态) -> binlog -> redo log(commit状态)

目录

redo log

binlog

为什么更新操作要用到两个日志模块？

更新操作的日志访问顺序

redo log

即重做日志。InnoDB引擎支持的回滚功能，就是依托在此日志之上做的。

对数据库的改变，也就是增删改操作，都会记录在redo log 中。

当出现意外，导致数据库内数据错误的时候，可以根据redo log 做回滚操作。

binlog

即归档日志。是MySQL自带的日志。

无法支持事务回滚，但可以实现数据备份。

为什么更新操作要用到两个日志模块？

理论上来讲，就更新操作本身而言，一个日志模块解决问题是可以的。

但是这里我们看到，两个日志模块，归属不同。一个是MySQL自带的，另一个是InnoDB引擎实现的。

更新操作的日志访问顺序

注意到更新操作中对日志的访问顺序是这样的：

redo log(prepare 状态) -> binlog -> redo log(commit状态)

这是为了保持两个日志的数据一致性。

如果先写redo log 再写 binlog ，在这中间出现意外，机器停止工作。那在重启后，机器会根据redo log 恢复数据，而在 binlog 里没有记录，进行备份的时候，就会丢失这一条数据。

如果先写 binlog ，后写 redo log ，在中间出现意外，数据无法恢复，但又存在记录。

按照交叉操作，如果在执行完 redo log(prepare 状态) -> binlog 出现意外，可以依赖MySQL的处理机制处理。

判断redo log 是否完整，完整则提交。

redo log 没有 commit ， 去看 binlog是否完整。

        完整，则提交 redo log 的commit 状态。

        不完整，回滚。

好了，这一篇就到这里了。

早睡早起，注意身体。早起之王祝你风生水起！