在这个例子中，进行完第三步之后，没来得及写binlog，然后主库就挂了，事务也没来得及提交。
这时主库从新启动之后会选择将这个事务丢弃，因为如果它将事务提交了，从库们相对主库来说就少了这条数据，造成了主从数据不一致问题
嗯，在看这个例子
在这个例子中主库宕机前虽然也没有完成对事务对提交，但是它已经写了redolog-prepare、还写了binlog，binlog写完之后很可能从库已经收到这个最新的binlog，并且将这个binlog中的数据回放到自己身上了。
所以主库重新启动之后呢，会选择按照redolog将宕机前的事务状态从内存中恢复出来，也就是说把内存中的缓存页改成脏数据页，然后提交事务
这时主库如果不提交事务，那主库就比从库少了一条数据，同时会造成主从不一致的情况出现。
白日梦补充：
嗯，你说的没错
而且一般我们线上的数据库都有这两个配置
# 该参数控制binlog的落盘时机# 设置为1表示当事务被提交时将binlog落盘# 设置为0表示由文件系统自己控制binlog的落盘时机sync_binlog=1# 该参数控制redolog的落盘时机 # 设置为1表示当事务被提交时将redolog落盘innodb_flush_log_at_trx_commit=1那你有没有想过：即使写日志是磁盘的顺序IO速度极快，即使固态硬盘的性能很