刚看了看MySQL的日志相关的东西，主要是redo-log和bin-log，虽然平时工作当中用不到，思考学习了一下，简单做下总结
比如做一个更新操作，主键ID为2的记录，字段a递增1
这里取了两个时间点，TimeA是写入redolog未commit，TimeB是写入了binlog
TimeA的时候崩溃，redolog虽然写入了，但是没提交，所以崩溃恢复的时候，事务会回滚，未更新成功；备份恢复的时候，binlog由于并没有写入，因此同样未更新成功；数据一致
TimeB的时候崩溃，redolog写入了，此时虽然没有commit，但是通过一个关联字段检查binlog，发现是完整的，因此崩溃恢复的时候还是会提交事务，更新a=a+1；binlog写入了，因此恢复的时候，会恢复更新后的结果，也就是a=a+1；数据一致
可以看到这里redolog整个写入的过程被分成了两部分，先写入redolog，但是没提交事务，然后写binlog到磁盘，最后才提交redolog才算完成
除了这种方式，可以看看另两种方案，要么binlog先写完，然后redolog；要么redolog先写完提交，然后binlog
第一种情况
TimeA的时候崩溃，redolog没写入，因此异常恢复的时候恢复的是a；binlog写入了，因此备份恢复的时候，恢复的是a=a+1；这样就导致两者数据不一致
TimeB的时候崩溃，redolog已写入，但是没提交，发现binlog完整，因此异常恢复的时候，会自动提交，从而恢复的是a=a+1；binlog写入了，因此备份恢复的时候，恢复的是a=a+1；数据一致
第二种情况
TimeA的时候崩溃，redolog写入了，但是没提交，也找不到完整的binlog，因此异常恢复的时候，会回滚，恢复的是a；binlog没写入，因此备份恢复的时候，恢复的是a；数据一致
TimeB的时候崩溃，redolog写入了并且已经提交，因此异常恢复的时候，恢复的是a=a+1；binlog没写入，因此备份恢复的时候，恢复的是a；数据不一致
综上可以看到，这两种方式，都会导致恢复的数据不一致
