【数据库】Update两阶段提交

事务提交之后，redo log和bin log 都是需要1持久化到磁盘中，但是这两个是独立的逻辑，可能出现半成功的状态，这样就造成两份日志之间的逻辑不一致。如：

以id=1，name = ‘小明’执行

update stu set name = '小红'  where id = 1

会出现如下两种情况：

如果bin log写入了磁盘之后，，Mysql突然宕机了，而redo log还没来得及写入。由于redo log没有写入数据，重启之后主库不存在这条数据，但是从库已经同步了这条数据就会出现，主从不一致的情况
如果在将redo log刷入到磁盘之后，Mysql突然宕机了，而bin log还没来得及写入。Mysql重启后，，通过redo log能将Buffer Pool中id = 1这行数据的name字段更新到‘小红’但是bin log由于没有写入，所以从库中的数据还是‘小明’，出现了主从不一致的情况

两阶段提交把单个事务提交分为两个阶段，分别是“准备”和“提交”阶段

当客户端执行commit语句或者在自动提交的情况下，Mysql内部开启一个XA事务，分为两个阶段来完成XA事务的提交

事务提交的过程分为两个阶段，就是将redo log的写入拆分为两个步骤：prepare和commit，中间在穿插写入bin log，具体步骤如下：

prepare阶段：将XID（内部XA事务的ID）写入到redo log，，同时将redo log对应的事务状态设置为prepare，然后将redo log持久化到磁盘
commit阶段：将XID写入到bin log然后将bin log持久化到磁盘，接着提交事务，将redo log状态设置为commit，此时该状态并不需要持久化到磁盘，只需要写入到文件系统的缓存页中就可以，因为只要bin log写到磁盘中成功，就算redo log状态还是prepare也没有关系，一样会被认为事务已经执行成功

异常重启会发送什么现象呢

不管是时刻A（redo log写入磁盘，bin log没有）出现问题还是时刻B（redo log和bin log都写入到磁盘，但是还没有写入commit标识）崩溃，此时得redo log都是处于prepare的状态

在Mysql重启之后，都会按照顺序扫描redo log文件，碰到处于prepare状态的redo log，就会拿着redo log中的XID去bin log中去查找是否存在这个XID：

可以看到，对于处于prepare阶段的redo log，既可以提交事务，也可以回滚事务，这取决于能否在bin log中查找到与redo log相同的XID，如果有就提交事务，没有就回滚事务。这样就可以保证redo log和 bin log的一致性

两个阶段虽然保证了两个日志文件的数据一致性，但是性能不高，主要的原因是：

磁盘I/O次数过高：每一个事务提交都是需要两次刷盘（redo和bin）
锁竞争激烈：两个阶段虽然可以保证“单个事务”的两个日志一致，但是不能保证“多个事务“情况下，两者提交的顺序一致性。因此，在两个阶段提交流程的基础上，还需要加上一个锁来保证提交的原子性，从而保证多事务的情况下，两个日志提交的顺序一致

为了解决上诉问题，引用有一个新的技术”组提交“,当多个事务提交的时候，会将多个bin log刷盘操作合并成一个，从而减少磁盘I/O的次数。如果10个事务一次排队刷盘的时间成本是10，那么将着10个事务一次性一起刷盘的时间成本近似.

引入组提交及之后，prepare阶段不变，只针对于commit阶段，将commit阶段拆分为三个过程：