Mysql两阶段提交

redo log： 

        innodb引擎特有的功能

        crash-safe： 数据库发生异常重启，之前提交的记录不会丢失。

        物理日志，记录的是 某个数据页上做了什么修改 。

        循环写，空间是固定的(比如为一组4个文件，每个文件1G)，如果写完，需要擦除之前写的记录，继续写

bin log：

        mysql server的功能，可以给每个引擎使用。

        逻辑日志，记录的是原始操作语句（update **），用于恢复数据，主从同步。

        追加写模式，binlog文件写到一定大小后，会切换到下一个文件写，不会覆盖之前的数据

执行器和innoDB引擎在执行一个 update user set age=age+1 where id =2; 语句时的内部流程。

1. 执行器先找引擎取id=2的这一行，id是主键，引擎直接用树搜索到这一行。如果这一行所在的数据页在内存中，就直接返回给执行器；否则，需要从磁盘读入到内存，再返回。

2. 执行器拿到行数据后，把age加上1，得到新的一行数据，再调用引擎接口写入这一行数据。

3.引擎将这行数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。

4.执行器生成这个操作的binlog，并把binlog写入磁盘。

5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成（commit）状态，更新完成。

为什么需要两阶段提交

用反证法来说明：

1. 先写redo log后写bin log。如果redo log写完后，binlog没写完的时候，Mysql服务重启，redo log会恢复数据。由于binlog里没有记录这条更新语句，因此，之后备份日志的时候，存起来的binlog里就没有这条语句，如果要用来恢复数据，那就会出现数据不一致的问题

2. 先写bin log后写redo log，如果bin log写完，redo log没写，崩溃恢复以后这个事务无效，所以数据还是原来的值，但是binlog里记录了age+=1的操作。所以后面恢复数据的时候，就会和原库数据不一致

补充：

在写入redolog的时候，会顺便记录事务id（xid），在写入bin log的时候也会写入事务id。因此会出现以下三种情况

1. 如果在写入redo log之前崩溃，此时redo log和bin log中都没有，是一致的情况，崩溃也无所谓。

2.如果在写入redo log prepare阶段后立马崩溃，之后会在恢复时，由于redo log中没有标记为commit，于是拿着reodo log中的xid去binlog中查找，此时肯定找不到，那么执行回滚操作。

3.如果在写入bin log后立马崩溃，再恢复的时候，由redo log中的xid可以在bin log中找到对应的bin log，直接提交就可以。

总结：在奔溃恢复后，只要redo log中不是commit阶段，就拿redo log中的xid去bin log中找，如果能找到则提交，找不到则回滚。