【IT168 评论】导读：前Facebook前工程师Eric Frenkiel 和 Nikita Shamgunov创办了MemSQL，对外宣称比MySQL快30倍。现在Facebook的MySQL工程师Domas Mituzas出来说话了，以下是其在个人博客的博文：
我不喜欢这个愚蠢的基准，这完全是在浪费我的时间。同样，我也不喜欢所谓的市场营销。当然了，有时我还是会关注一下这些东西，现在我就占用你们点些时间来谈谈。
所谓的MemSQL，是由一群聪明的小伙儿鼓捣出来的，他们现在正在媒体和技术社区“兴风作浪”。他们的核心论断即：“MemSQL比传统基于磁盘的数据库快30倍。”
虽然他们这样说没什么意义，但我想知道他们到底哪里做错了。MySQL和MemSQL都在默认设置下运行。他们说这是一个好的基准，通过安装标准包来比较用户体验。
这已经是在说瞎话了，系统必须在完全不同的配置文件中运行。例如，用于数据缓冲的内存在MemSQL中本质上是解除绑定的，而InnoDB在MySQL5.5把它限制在了128MB，这是MySQL5.1默认设置的16倍。
至于写入性能方面，MemSQL 能写出2G的快照日志，而InnoDB设置为10MB的事务日志，所以会更快地开始检查点。尽管如此，对于基准来说，稳定持久是最重要的。
MemSQL宣称支持ACID，其中耐久性是最重要的一环。MySQL的InnoDB默认是很耐用的，如果事务返回为“同意”，就会在崩溃后刻到磁盘上。MemSQL默认也是很“耐久”的，它也会有一个事务日志，而这并不意味着跟磁盘有关。
MemSQL也有事务缓冲设置，默认“完全耐久性模式”会不同时地返回“同意”直到128M缓冲区充满。本质上这跟innodb_flush_log_at_trx_commit=2很相似，在我看来不会很持久。
如果MemSQL激活了完全的耐久性会发生什么呢?结局肯定是悲剧。每次提交都得等后台线程才能写事务日志。多久后台线程才能醒一次?50毫秒一次。MemSQL其实是玩的是计时戏法，每50毫秒冲一次，然后说后台线程一直没醒。
吐槽点一：MemSQL每秒持久事务比InnoDB慢500倍
这一点很容易证明：在磁盘阵列控制器的后写式缓存模式下，InnoDB能够轻易的维持单线程每秒10K的事务，在fsyncs空隙不会停50毫秒。有一些提交分组，两个线程有40tps，十个线程有200tps，但当我选择自己的基准时，MemSQL单线程持久事务率会变得更慢。
既然我们已经确立了MySQL的领先优势，让我们一起来看读写的表现。我敢肯定这方面MemSQL的表现会大亮。MemSQL扫描表的执行速度还是不错的，每秒扫描8M行，这对单线程来说是很了不起的成就。
说实话，我不想花时间用基准问题测试内存数据库所擅长的。我决定测试我最爱的查询：
网上到处是这个查询，MySQL 通过指向索引位置的游标，然后按照指标顺序逐步游动。而MemSQL实际上必须穿越整个目录，分类提供响应。即使是“SELECT MAX(id)”也需要穿越整个目录。
吐槽点二：MemSQL在做一些简单的读写查询时，比MySQL慢上千倍，也许是慢百万倍
我们假设MemSQL在一些普通运算有O(N) performance，因此我们只需找到那个足够大的N。我不知道我们应该如何责备MemSQL的研发人员和被他们误导的那些记者朋友。如果我们回到ACID，A代表原子性，只在语句级实现，BEGIN/COMMIT被无视了。隔离性是提交读。持久性是有缺陷的，我不关心字母C所代表的。我必须承认，MemSQL常见问题中说，MemSQL支持完整ACID事务，当然了，说是这么说。
MemSQL每秒80000次查询没什么值得炫耀的，因为现在MySQL有了HandlerSocket，计算能力接近每秒百万次。当然了，他们也有自己擅长的事情，目前是最快的 MySQL 协议，当然也没超出MySQL Cluster多少。NDB也有很不错的表现。我确信，我上面的两则声明会被一些技术工作所完善。写入性能需要适当的实时与分组提交同步(虽然二进制日志所涉及的工作很复杂，MySQL 最近还是推出了几项重大更新)。
读取性能需要实现最常见模式的最优化，例如按索引顺序读取。内存是快，但还没快到高并发环境所需要的一遍又一遍的重复读取。即使在MemSQL表现良好的部分，我也怀疑MemSQL的内存工作负载能否超过InnoDB30倍。今天我就不做基准测试了，但我还是能很轻易的证明这一点。
无论如何，如果我们清楚MemSQL的一系列动作或是有一个不错的标杆管理的话，也就不需要我这篇稿子了。接下来我们就开始测试吧，然后得出属于自己的结论。
文章来源：dom.as
