MySQL通过两阶段提交解决了服务层binlog与引擎层Innodb的redo log的一致性与协同问题。
第一阶段：InnoDB prepare,持有prepare_commit_mutex，并写入到redo log中。将回滚段(undo)设置为Prepared状态，binlog不做任何操作。
第二阶段：将事务写入Binlog中，将redo log中的对应事务打上commit标记，并释放prepare_commit_mutex。
MySQL以binlog的写入与否作为事务是否成功的标记，innodb引擎的redo commit标记并不是这个事务成功与否的标记。
崩溃时：
扫描最后一个Binlog文件，提取其中所有的xid。
InnoDB维持了状态为Prepare的事务链表，将这些事务的xid与刚刚提取的xid做比较，若存在，则提交prepare的事务，若不存在，回滚。
2.两阶段的加锁在事务中只有提交(commit)或者回滚(rollback)时才是解锁阶段，
其余时间为加锁阶段。
在对记录更新操作或者(select for update、lock in share model)时，会对记录加锁(有共享锁、排它锁、意向锁、gap锁、nextkey锁等等)
加锁阶段：只加锁，不放锁。解锁阶段：只放锁，不加锁。
由于Mysql的事务日志包含二进制日志和存储引擎日志，当发生崩溃恢复时，MySQL主节点通过redo log进行恢复，而在主从复制的环境下，slaver节点是依据于主节点的binlog进行同步数据的；这样的架构于是对mysql的二进制日志和redo log，就有两个基本要求：第一，保证binlog里面存在的事务一定在redo log里面存在，也就是binlog里不会比redo log多事务（可以少，因为redo log里面记录的事务可能有部分没有commit，这些事务最终可能会被rollback）。 2、顺序一致，这也是很重要的一点，假设两者记录的事务顺序不一致，那么会出现类似于主库事务执行的顺序是ta, tb, tc,td，但是binlog里面记录的是ta,tc, tb, td，binlog复制到从库后导致主从的数据不一致。为了达到上面说的两点，mysql是怎么来实现的呢？没错，答案是内部xa事务（核心是2pc）
写binlog是一定已经提交的数据，只要写了binlog，事务是铁定要提交成功的。因为主从复制环境下，写了binlog就可能直接传输到从节点应用了，所以两阶段提交很好的保持数据一致性和顺序性。