prepare_commit_mutex锁
MySQL5.6以前，为了保证数据库上层二进制日志的写入顺序和InnoDB层的事务提交顺序一致，MySQL数据库内部使用了prepare_commit_mutex锁。但是持有这把锁之后，会导致组提交失败。锁的持有与释放在二阶段中如下：
InnoDB prepare （持有prepare_commit_mutex）；
write/sync Binlog；
InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex)。
这样事务提交就是一个一个执行，导致组提交失败。
Binary Log Group Commit（BLGC）
MySQL5.6通过BLGC的方式实现了binlog的组提交。
binlog组提交的基本思想是，引入队列机制保证innodb commit顺序与binlog落盘顺序一致，并将事务分组，组内的binlog刷盘动作交给一个事务进行，实现组提交目的。
binlog提交将提交分为了3个阶段，FLUSH阶段，SYNC阶段和COMMIT阶段。每个阶段都有一个队列，队列中的第一个事务称为leader，其他事务称为follower，leader控制着follower的行为。BLGC的步骤分为以下三个阶段：
FLUSH阶段：
持有Lock_log mutex [leader持有，follower等待]
获取队列中的一组binlog(队列中的所有事务)
将binlog buffer到I/O cache
通知dump线程dump binlog
SYNC阶段：
释放Lock_log mutex，持有Lock_sync mutex[leader持有，follower等待]
将一组binlog 落盘(sync动作，最耗时，也是group commit实现了的优化的重点所在)
COMMIT阶段：
释放Lock_sync mutex，持有Lock_commit mutex[leader持有，follower等待]
遍历队列中的事务，逐一进行innodb commit（这里不用写redo log，在prepare阶段已写）
释放Lock_commit mutex
唤醒队列中等待的线程
每个stage分配一个线程进行操作。
这种实现的优势在于三个阶段可以并发执行，从而提升效率。（PS：innodb prepare阶段没有变，还是write/sync redo log，打上prepare标记）
每个stage都有自己的队列。每个队列各自有mutex保护，队列之间是顺序的。只有flush完成后，才能进入到sync阶段的队列中；sync完成后，才能进入到commit阶段的队列中。但是，这三个阶段的作业是可以同时并发执行的，即当一组事务在进行commit阶段时，其他新事务可以进行flush阶段，实现了group commit。
当一个事务来到一个stage是一个空队列，那么他就是leader，后面来的事务就是follower，leader控制队列中follower的行为。如果leader带着自己的follower去下一个stage，是非空队列，那么leader变成follower。但是follower不会变成leader。
Tips：当引入Group Commit后，sync_binlog的含义就变了，假定设为1000，表示的不是1000个事务后做一次fsync，而是1000个事务组。也就是说，当设置sync_binlog=1，binlog还未落盘，此时系统crash，会丢失对应的最后一个事务组；如果这个事务组内有10个事务，那么这10个事务都会丢失。
如何查看是否属于一个事务组：通过mysqlbinlog可以查看binlog日志中last_committed值，如果值一样，表明是在同一事务组内。
### INSERT INTO `wukong_test`.`wukong` ### SET ### @1=3 /* INT meta=0 nullable=1 is_null=0 */ ### @2='ccccc' /* VARSTRING(80) meta=80 nullable=1 is_null=0 */ # at 496468 #170527 4:17:35 server id 12001 end_log_pos 496499 CRC32 0xd6e7f69f Xid = 5556 COMMIT/*!*/; # at 496499 #170527 4:17:35 server id 12001 end_log_pos 496564 CRC32 0x28816d5c GTID last_committed=1845 sequence_number=1846 SET @@SESSION.GTID_NEXT= '0a646c88-36e2-11e7-937d-fa163ed7a7b1:3624'/*!*/; # at 496564 #170527 4:17:35 server id 12001 end_log_pos 496632 CRC32 0x03150d48 Query thread_id=1852 exec_time=0 error_code=0 SET TIMESTAMP=1495873055/*!*/; BEGIN
