出于性能的考虑，事务在提交时为了保证数据安全，需要将 redo 和 undo 数据落盘，不用等待数据落盘。但是 mysql 不仅要考虑 innodn 存储引擎层的 redo 数据，还要考虑数据库上层的 binlog 数据落盘，已经两个层面数据落盘的顺序问题。两阶段提交可以解决单个事务 redo 和 binlog 落盘顺序的问题。
两阶段提交（ 2PC ）分为两个过程：
l 准备阶段（ prepare phase ）
生成 xid 信息，回滚段设置为 prepare 状态，并将 redo 落盘。
l 提交阶段（ commit phase ）
在 binlog 生成 commit 的 XID event ， Binlog 落盘，释放回滚段，释放锁。
二阶段提交的回滚： 只写了redo，没落盘binlog，回滚。
落盘了redo，binlog落盘成功了，也有commit XID，自然是成功。
落盘了redo，binlog落盘成功了，没有commit XID，也认为事务已提交。
现在再来思考下一个问题，如果每个事物提交的时候，都要去将 redo 和 binlog 落盘，那么瓶颈就在落盘阶段被放大了。这个时候就要引入组提交。组提交使得 redo 和 binlog 落盘的时候可以批量落盘，多个事务的 redo 和 binlog 可以一次 fsync 操作完成数据落盘，减少了 fsync 函数的调用，提高了效率。同时 innodb 存储引擎层本身就支持组提交。
组提交之后，引入了另一个问题。数据库上层的 binlog 写入顺序和 innodb 层事务提交顺序无法保持一致。如果不保持一致，那么就会出现通过在线工具比如 xtrabackup 备份数据库搭建主从的时候，出现丢失事务的场景，比如下面：
binlog 提交顺序（ T1,T2,T3 ）， innodb commit 顺序（ T2,T3,T1 ），此时 innodb 检测到 T3 上下两层都已经提交，认为不再需要恢复，那么 T1 事务在备份的时候没有经历两阶段提交， T1 的事务在备份的时候数据还是事务开始前的数据，从库又不再进行恢复，导致 T1 事务被丢弃。所以后来引进了 prepare_commit_mutex, 以串行的方式来保证顺序，但是这样会使组提交失效，所以后来提出了 BLGC （ binary log group commit ）
该行为分为三个阶段
Flush 阶段
内存中生成事务的二进制日志
Sync 阶段
将内存中多个事务的二进制日志调用 1 次 fsync 刷盘
Commit 阶段
二进制日志在内存中会有一个队列，队列第一个事务是 leader ，其他时 follower ， leader 会根据顺序调用存储引擎层事务提交。 Innodb 本身就支持组提交。
