组提交 (group commit) 是为了优化写日志时的刷磁盘问题，从最初只支持 InnoDB redo log 组提交，到 5.6 官方版本同时支持 redo log 和 binlog 组提交，大大提高了 MySQL 的事务处理性能。
下面将以 InnoDB 存储引擎为例，详细介绍组提交在各个阶段的实现原理。
简介自 5.1 之后，binlog 和 innodb 采用类似两阶段提交的方式，不过不支持 group commit；在 5.6 中，将 binlog 的 commit 阶段分为三个阶段：flush stage、sync stage 以及 commit stage。
这三个阶段中，每个阶段都会去维护一个队列，各个列表的定义如下。
Mutex_queue m_queue[STAGE_COUNTER];如上，每个阶段都在维护一个队列，第一个进入该队列的作为 leader 线程，否则作为 follower 线程；leader 线程会收集 follower 的事务，并负责做 sync，follower 线程等待 leader 通知操作完成。
尽管维护了三个队列，但队列中所有的 THD 实际上都是通过 next_to_commit 连接起来。binlog 在事务提交阶段，也就是在 MYSQL_BIN_LOG::ordered_commit() 函数中，开始 3 个阶段的流程。
接下来，看看 MySQL 中事务是如何提交的。
事务提交接下来，看看 InnoDB 和 binlog 提交的流程。
二阶段提交详细介绍下二阶段提交的过程。
未开启binlog时InnoDB 通过 redo 和 undo 日志来恢复数据库 (safe crash recovery)，当数据恢复时，通过 redo 日志将所有已经在存储引擎内部提交的事务应用 redo log 恢复，所有已经 prepared 但是没有 commit 的事务则会通过 undo log 做回滚。
然后客户端连接时就能看到已经提交的数据存在数据库内，未提交被回滚地数据需要重新执行。
开启binlog时为了保证存储引擎和 MySQL 的 binlog 保持一致，引入二阶段提交 (two phase commit, 2pc) 。
因为备库通过 binlog 重放主库提交的事务，假设主库存储引擎已经提交而 binlog 没有保持一致，则会使备库数据丢失造成主备数据不一致。
二阶段提交如下是二阶段提交流程。
详细执行流程为：
InnoDB 的事务 Prepare 阶段，即 SQL 已经成功执行并生成 redo 和 undo 的内存日志；
binlog 提交，通过 write() 将 binlog 内存日志数据写入文件系统缓存；
fsync() 将 binlog 文件系统缓存日志数据永久写入磁盘；
InnoDB 内部提交，commit 阶段在存储引擎内提交，通过 innodb_flush_log_at_trx_commit 参数控制，使 undo 和 redo 永久写入磁盘。
开启 binlog 的 MySQL 在崩溃恢复 (crash recovery) 时：
在 prepare 阶段崩溃，恢复时该事务未写入 binlog 且 InnoDB 未提交，该事务直接回滚；
在 binlog 已经 fsync() 永久写入 binlog，但 InnoDB 未来得及 commit 时崩溃；恢复时，将会从 binlog 中获取提交的信息，重做该事务并提交，使 InnoDB 和 binlog 始终保持一致。
以上提到单个事务的二阶段提交过程，能够保证 InnoDB 和 binlog 保持一致，但是在并发的情况下怎么保证存储引擎和 binlog 提交的顺序一致？当并发提交的时，如果两者不一致会造成什么影响？
组提交异常首先看看，对于上述的问题，当并发提交的时，如果两者不一致会造成什么影响？
如上所示，事务按照 T1、T2、T3 顺序开始执行，并依相同次序按照写入 binlog 日志文件系统缓存，调用 fsync() 进行一次组提交，将日志文件永久写入磁盘。
但是存储引擎提交的顺序为 T2、T3、T1，当 T2、T3 提交事务之后做了一个 On-line 的备份程序新建一个 slave 来做复制；而搭建备库时，CHANGE MASTER TO 的日志偏移量在 T3 事务之后。
那么事务 T1 在备机恢复 MySQL 数据库时，发现 T1 未在存储引擎内提交，那么在恢复时，T1 事务就会被回滚，此时就会导致主备数据不一致。
结论：需要保证 binlog 的写入顺序和 InnoDB 事务提交顺序一致，用于 xtrabackup 备份恢复。
早期解决方案早期，使用 prepare_commit_mutex 保证顺序，只有当上一个事务 commit 后释放锁，下个事务才可以进行 prepara 操作，并且在每个事务过程中 binlog 没有 fsync() 的调用。
