MySQL Innodb Redo Log两阶段提交 和 BinLog之间的调用执行顺序

一、RedoLog和Binlog区别

1. redo log 是 InnoDB 引擎特有的；
    binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
2. redo log 是逻辑物理日志，页面内的操作记录的是逻辑日志，页间的操作记录的是物理日志；
    binlog 是逻辑日志，相当于是Mysql server层的日志，适用于所有引擎，且可以通过参数控制写入。
3. redo log 是循环写的，空间固定会用完；
    binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

备注：

数据库的日志类型大概可以分为以下三种：
逻辑日志：记录的是sql语句的原始逻辑，面向对象是逻辑结构如表、列等
物理日志：记录的是文件记录的改变，面向对象是表空间、数据文件、数据页、偏移量等
逻辑物理日志：页面内的操作记录的是逻辑日志，页间的操作记录的是物理日志，physical to a page，logical within a page

二、执行流程与恢复

一条更新语句的执行流程为：

数据页到内存中——>修改数据——>更新数据页——>写入redolog（状态为prepare）——>写binlog——>提交事务（redolog状态修改为commit）

使用两阶段提交的优势就是如果数据库发生了意外情况，宕机、断点、重启等等，可以保证使用BinLog恢复数据和当时数据状态一致；

具体情况下的策略如下：

binlog	redolog	恢复操作	说明
有记录	prepare	继续提交事务	在binlog写完之后，且在提交事务之前的crash
	commit	无	正常完成的事务
无记录	prepare	回滚事务	在binlog写完之前的crash
	无记录	回滚事务	在redolog写之前crash

三、小结

innodb_flush_log_at_trx_commit（默认值1）

redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。
这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。

sync_binlog（默认值1）

sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。
这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。

————————————————
参考自，对原文格式排版有改动：mysql redo log为什么有两阶段提交/为什么有prepare和commit两个状态？_wu_55555的博客-CSDN博客_prepare和commit

另外图片来自：MySQL日志系统redo log(两阶段提交)和binlog_掉发的小王的博客-CSDN博客_redolog 两阶段提交