12月5日Steinar Gunderson在博客上发的那封离开Oracle Mysql优化器研发团队，返回老东家谷歌的离职感言注定是会掀起轩然大波的，因为这又会刺激到很多人脆弱的神经。Steinar H. Gunderson在业界也只能算是个小人物，他加入到Mysql优化器研发团队之前在谷歌从事离线图像搜索工作，这回又回到谷歌，加入chrome团队。不过如果仔细研究过Steiner的简历后发现他虽然从事的工作不多，但是都是极为强大的，比如说为国际象棋世锦赛提供实时分析预测的那个超级计算程序也出自他的手。我想他在Mysql优化器研发团队中的角色应该也是一个重要骨干。

在Oracle这的几年可能Steinar积压了太多的怒火，他同时在reddit，sesse.net，the register，Hacker News等多个网站上发布了这个博客，并且引起了一大批Mysql的拥趸和反对者在上面论战。

我是今天收到了一个朋友发来的一篇中文的文章才了解到这件事的，随后到各大网站去看了看。发现谷歌搜索搜出来的大多数是中文的文章，英文的文章很少，而且大多数是转述该博文，并未做任何的评论和分析。下面我首先全文转发一下这篇不是很长，但是充满抱怨的博文。如果你没有兴趣读大段的英文，那么你完全可以跳过，看后面的谷歌翻译的中文。

贴出原文的目的是我发现看中文的转述文章会丢失很多细节。从Steiner的博文中，我看到的很多是对MySql项目组的治理感到失望后的激烈反应，并不完全是从理性的技术角度的分析。他加入Mysql优化器项目组是被Oracle官方宣传的“只有最聪明的人才能加入Oracle的研发团队”所吸引，但是进入项目组后才发现完全不是这么回事。

为了更加便于大家阅读，我把谷歌翻译称中文的内容也贴出来，虽然翻译的不完全准确，不过大致可以理解Steiner的意思了。这篇文章已经发布了几天了，不过Oracle官方并未对此做出任何回应。不过鉴于Steiner只是一个小人物，Oracle官方不予理睬也十分正常。

不过Mariadb的联合创始人Max Mether在7号回复了Steiner的博文。他的观点还是很客观的。翻译过来的意思是：没有一个数据库是完美的。不同的模型，存储引擎，协议等都证明了这一点。我在数据库领域工作了十分常长的时间，我已经看到了很多人来了又走了。这是自然规律。这是一场拉锯战，有时候你赢，有时候他赢，或者某一方停留在过去。我要说明的是：无论你怎么看，Oracle旗下的Mysql注定是迷失方向的，Mysql在Oracle内部被抛弃并且受到大量的用户的攻击。这位工程师的blog正好证明了我以前的对MYSQL的观点。最后Mether重申：2016年，在MariaDB上，我们几乎重构了Mysql的代码，并且编写了新的存储引擎，语法，监控，甚至引入了基于机器学习的工作负载分析引擎。这个回复也符合Mether的性格，比较客观的回应了此事，又不放过在这个时候猛踩Oracle两脚。

不出所料，在Reddit和Hacker News上，这条博文很快就成为了Mysql和PG拥趸的战场。出了少量力挺oracle的条目外，其他都是Mysql和PG哪个数据库更好的辩论。

说实在的，一直在从事和数据库有关的工作，因此接触的大多数人都是这个圈子里的。我也曾遇到过很多Mysql的狂热拥趸:“MYSQL是最好的数据库，不接受反驳”。Steiner的博文中还特地提到了这类人，认为这类人从来没有使用过其他数据库，从而让他们产生了对Mysql是最好的这样的执念。

虽然这篇博文充满了Steiner对团队的怒火，不过从里面的一些细节我可看到了Mysql的一些隐忧。研发团队似乎处于一个“平行宇宙”，并且妄自尊大，会让他们失去向其他先进、创新的技术学习的能力，从而逐渐落后。而团队中的那种执念也可能会让整个产品在某条错误的道路上越走越远，并且没有人会站出来纠正。而Steiner在文中建议的离开Mysql，投入PG的怀抱，他并没有说出其中的缘由。

作为Mysql团队曾经的一员，他的上面的这句话是极具杀伤力的，不过他在博文中并没有谈更多的选择PG替代MYSQL的理由。只是说，如果你的MYSQL用的很好，那么你可以继续使用，不过如果你有空的时候，也可以抬头看看栅栏的那一边，去看看PG数据库，并且不要带着对vaccum的执念。

正如Mether所说，没有任何一个数据库是完美的，我的观点也是如此。我们需要根据我们的应用场景和自身的运维能力来选择合适的数据库。Mysql也并不像Steiner说的那么不堪，如果你的数据库规模不大，应用系统开发也相对比较规范，那么使用Mysql可能是一个比较节约投资的选择。如果你的数据库很大，不过几乎所有的SQL都很简单，都可以通过索引去检索，那么你也可以十分坚决的使用MYSQL。如果你的SQL十分复杂，很多大表的访问都无法确保可以通过索引建索少量的行。那么如果你坚持使用MYSQL很可能会遇到巨大的挑战，这时候PostgreSQL甚至Oracle是更好的选择。

PG社区创始人之一Bruce MomJian曾经发过一篇博文，讲述了不该选择PG数据库的6个场景。实际上作为PG社区的大佬，他对PG的感情是相当深的，不过他的博文中十分专业的提出了很多不选择PG数据库的原则。这些原则里并无太多技术相关的因素，绝大多数是从企业自身特点和应用场景去考虑问题的。实际上目前普通企业使用的数据库，超过90%的场景是使用通用数据库。而不同的通用数据库的主要差异是在部分语法、并发能力与性能上的，并不是存在技术鸿沟的。企业选择使用哪种数据库可以根据自己的应用场景与企业自身的情况去综合分析，做出决策。正是基于此，在MYSQL/PG两大阵营中，不乏抛弃某个阵营加入另外一个阵营的例子，比如2016年UBER因为vacuum的问题放弃PG 9.2,转投Mysql 5.7,不过这种选择更多的是基于业务特征的选择，而并不能说明两种数据库的技术差异。UBER放弃PG的主要原因是从存储引擎来考虑的，因为他们的业务大多数都是可以通过索引获得少量的数据，并且存在大量的UPDATE，因此PG的VACUUM会成为一个无法解决的瓶颈，而MYSQL的BTREE存储引擎正好契合度很高。而如果你有很多大表扫描的业务需求的时候，MYSQL的BTREE存储引擎可能就是个噩梦了。曾经有过一个MYSQL的拥趸和我争论，你完全可以去优化应用的结构，改变用户的使用习惯，让应用总是能很好的使用索引。这近乎一种偏执了。和规范性相当好的互联网业务相比，复杂的企业应用，没那么容易去把所有的应用都整合为一种简单的模式。

这次由Steiner引发的论战其实对我们来说也是一件好事情，在最近这些年里，我们听到了太多的关于MYSQL的赞誉之词，甚至我见过的十个企业的IT高管里，至少有8个认为Mysql是他们企业数据库未来的首选。也许通过这场论战，会让这些不太懂数据库的领导能够更加客观的评价数据库，更加客观的考虑数据库选型。在一个企业里只选择一种数据库可能不是一个特别好的选择，根据业务系统的特点去选择几种数据库来支撑企业的IT系统可能是一种更为理智的选择，虽然运维多种数据库可能会给企业带来一些额外的成本。