今天发现Percona Release的Percona-Server-5-5-18-23-0已经完成了GroupCommit工作，而且是用最优雅的方式（移植了MariaDB数据库的实现，而不是workaround），心里难掩激动。这篇文章接前篇继续介绍一下问题
这篇文章接前篇继续介绍一下问题的背景：什么是Group Commit，现在的官方版本Group Commit做到了什么程度？
1. 什么是Group Commit
MySQL数据库InnoDB存储引擎在做事务的时候，使用的日志先行（Write-ahead logging）的方式保证事务的快速和持久，所以每次事务完成都要求日志必须持久化到磁盘，在Linux上对应的操作就是“write and fsync”，write 速度是很快的，一般对应的写Page Cache，而fsync则要求文件系统把对应文件的哦Page Cache必须持久化到磁盘上，而对于传统磁盘一次写操作大约需要1~3ms（不说BBU），这意味着对于传统磁盘1秒钟最多最多做333～1000个事 务，这是不理想的，对硬件的利用率（吞吐量）也是非常低。 所以，这里就有了Group操作的概念，即当好几个线程都要fsync同一个日志文件时，我们将这些fsync合并到一次来做。简单举例：我们让系 统每2ms做一次fsync，这样如果这2ms内有100个线程都需要做fsync，那就赚到了，原本100个fsync都独立来做那耗时会非常多的。
你肯定会说，难道这不是很简单的想法吗？是的，这就是原本是很简单、也很自然的想法。
但对MySQL来说却变成了一种奢求（看看这个Bug讨论）。
2. 为啥MySQL一直没有实现？
MySQL是不是太弱了，这么简单的事情都搞不定？不是的。
MySQL从开源到现在，成功的一个非常重要的原因，就是MySQL的插件式架构。如果MySQL只是MyISAM估计不会有现在的流行程度，插件 式的架构让诸如Heikki Tuuri有了发挥空间，在InnoDB和MySQL一起时，MySQL才能算是一个真正的DBMS。再到后来，有Infobright、 FEDERATED、PBXT等等。
插件式的架构给MySQL带来了活力，做出牺牲便是在上层(MySQL)和下层(存储引擎)交互时带来的额外消耗，有时甚至上层和下层需要做一些重复工作。无法做Group Commit就是这其中的牺牲之一。
3. 现在的官方版本Group Commit做到了什么程度
InnoDB在一次事务中，有两次fsync，分别是prepare阶段和commit阶段，对于这两次操作InnoDB都是实现了Group操作的。
如果你设置了binlog_sync=1，则又多了一次fsync操作（参考MYSQL_BIN_LOG::flush_and_sync），这次操作在innobase_xa_prepare和innodb_commit之间：
binlog_prepare (do nothing)
innodb_prepare
…
binlog_commit
innobase_commit
这次fsync，在MySQL中一直都无法做Group。所以，一直以来当innodb_flush_log_at_trx_commit和binlog_sync都等于1的时候，MySQL数据库的性能就非常、非常糟糕。原因是为了保证InnoDB内部Commit的顺序和MySQL日志的顺序一致（参考）。
4. 开源社区的努力
难道没人去解决这个问题吗？不是的。有很多人已经做出了努力，直到Kristian Nielsen@MariaDB提出了理论和实际上的最优解决方案。
Mark Callaghan@Facebook关于Group Commit做的工作：FB的基本实现 | FB的问题和改进 | 性能 | 对比MariaDB的实现(对比的结果是MariaDB完胜，无论是方案架构还是性能)
Facebooke可以说是通过一个Trick快速实现了Group Commit。而Kristian Nielsen@MariaDB这是从架构上根本的解决了这个问题。
MariaDB数据库关于Group Commit架构和实现： WL116 | WL132 | WL164
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
