该问题问的其实就是redo log 的两阶段提交

为什么说redo log 具有崩溃恢复的能力

MySQL Server 层拥有的 bin log 只能用于归档，不足以实现崩溃恢复（crash-safe），需要借助 InnoDB 引擎的 redo log 才能拥有崩溃恢复的能力。所谓崩溃恢复就是：即使在数据库宕机的情况下，也不会出现操作一半的情况

至于为什么说 redo log 具有崩溃恢复的能力，而 bin log 没有，我们先来简单看一下这两种日志有哪些不同点：

1）适用对象不同：

bin log 是 MySQL 的 Server 层实现的，所有引擎都可以使用
而 redo log 是 InnoDB 引擎特有的

2）写入内容不同：

bin log 是逻辑日志，记录的是这个语句的原始逻辑，比如 “给 id = 1 这一行的 age 字段加 1”
redo log 是物理日志，记录的是 “在某个数据页上做了什么修改”

3）写入方式不同：

bin log 是可以追加写入的。“追加写” 是指 bin log 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志
redo log 是循环写的，空间固定会被用完
可以看到，redo log 和 bin log 的一个很大的区别就是，一个是循环写，一个是追加写。也就是说 redo log 只会记录未刷入磁盘的日志，已经刷入磁盘的数据都会从 redo log 这个有限大小的日志文件里删除。

而 bin log 是追加日志，保存的是全量的日志。这就会导致一个问题，那就是没有标志能让 InnoDB 从 bin log 中判断哪些数据已经刷入磁盘了，哪些数据还没有。

举个例子，bin log 记录了两条日志：

记录 1：给 id = 1 这一行的 age 字段加 1
记录 2：给 id = 1 这一行的 age 字段加 1

假设在记录 1 刷盘后，记录 2 未刷盘时，数据库崩溃。重启后，只通过 bin log 数据库是无法判断这两条记录哪条已经写入磁盘，哪条没有写入磁盘，不管是两条都恢复至内存，还是都不恢复，对 id = 1 这行数据来说，都是不对的。

但 redo log 不一样，只要刷入磁盘的数据，都会从 redo log 中被抹掉，数据库重启后，直接把 redo log 中的数据都恢复至内存就可以了。

这就是为什么说 redo log 具有崩溃恢复的能力，而 bin log 不具备。

redo log 两阶段提交

查询语句

前面我们介绍过一条 SQL 查询语句的执行过程，简单回顾：

1、MySQL 客户端与服务器间建立连接，客户端发送一条查询给服务器；

2、服务器先检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果；否则进入下一阶段；

3、服务器端进行 SQL 解析、预处理，生成合法的解析树；

4、再由优化器生成对应的执行计划；

5、执行器根据优化器生成的执行计划，调用相应的存储引擎的 API 来执行，并将执行结果返回给客户端

更新语句

对于更新语句来说，这套流程同样也是要走一遍的，不同的是，更新流程还涉及两个重要的日志模块 bin log 和 redo log。

以下面这条简单的 SQL 语句为例，我们来解释下执行器和 InnoDB 存储引擎在更新时做了哪些事情：

update table set age = age + 1 where id = 1;

1、执行器：找存储引擎取到 id = 1 这一行记录

2、存储引擎：根据主键索引树找到这一行，如果 id = 1 这一行所在的数据页本来就在内存池（Buffer Pool）中，就直接返回给执行器；否则，需要先从磁盘读入内存池，然后再返回

3、执行器：拿到存储引擎返回的行记录，把 age 字段加上 1，得到一行新的记录，然后再调用存储引擎的接口写入这行新记录

4、存储引擎：将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务

5、执行器：生成这个操作的 bin log，并把 bin log 写入磁盘

6、执行器：调用存储引擎的提交事务接口

7、存储引擎：把刚刚写入的 redo log 状态改成提交（commit）状态，更新完成

可以看到，所谓两阶段提交，其实就是把 redo log 的写入拆分成了两个步骤：prepare 和 commit。

所以，为什么要这样设计呢？这样设计怎么就能够实现崩溃恢复呢？

根据两阶段提交，崩溃恢复时的判断规则是这样的：
1、如果 redo log 里面的事务是完整的，也就是已经有了 commit 标识，则直接提交
2、如果 redo log 里面的事务处于 prepare 状态，则判断对应的事务 binlog 是否存在并完整
a. 如果 binlog 存在并完整，则提交事务；
b. 否则，回滚事务。

注： MySQL 咋知道 bin log 是不是完整的？
简单来说，一个事务的 binlog 是有完整格式的：
1、statement格式的 bin log，最后会有 COMMIT
2、row 格式的 bin log，最后会有 XID event

实际的例子

1、假设数据库在写入 redo log(prepare) 阶段之后、写入 binlog 之前，发生了崩溃，此时 redo log 里面的事务处于 prepare 状态，binlog 还没写，所以崩溃的时候，这个事务会回滚。

由于 binlog 还没写，所以也就不会传到备库，从而避免主备不一致的情况

2、如果数据库在写入 binlog 之后，redo log 状态修改为 commit 前发生崩溃，此时 redo log 里面的事务仍然是 prepare 状态，binlog 存在并完整，所以即使在这个时刻数据库崩溃了，事务仍然会被正常提交。

因为 binlog 已经写入成功了，这样之后就会被从库同步过去，但是实际上主库并没有完成这个操作，所以为了主备一致，在主库上需要提交这个事务。

其实可以看出来，处于 prepare 阶段的 redo log 加上完整的 bin log，就能保证数据库的崩溃恢复了。

如果数据库在写入 binlog 之前，此时 redo log 里面的事务是 prepare 状态，binlog 存在但不完整，在这个时刻数据库崩溃了，事务就会被回滚。

redo log两阶段提交的重要性（可不可以先 redo log 写完，再写 bin log 或者反过来？）

1）对于先写完 redo log 后写 bin log 的情况：

假设在 redo log 写完，bin log 还没有写完的时候，MySQL 崩溃。主库中的数据确实已经被修改了，但是这时候 bin log 里面并没有记录这个语句。因此，从库同步的时候，就会丢失这个更新，和主库不一致。

2）对于先写完 binlog 后写 redo log 的情况
如果在 bin log 写完，redo log 还没写的时候，MySQL 崩溃。因为 binlog 已经写入成功了，这样之后就会被从库同步过去，但是实际上 redo log 还没写，主库并没有完成这个操作，所以从库相比主库就会多执行一个事务，导致主备不一致