开源数据库的战争：MYSQL vs PostgreSQL

这张表只是列出了一部分对比项，也许带啊也很难从中看出一个到底哪个数据库更好。确实是这样的，企业选择一个数据库产品并不是简单的技术对比，而是一种十分复杂的过程，其中涉及很多方面，包括业务应用特点、数据库技术水平、数据库技术特点与业务的吻合度、企业对数据库的掌握能力、售后服务水平、第三方服务能力、生态与工具。另外一点，也就是最关键的一点，决策者对二者的好感度。

我们的数据库选型的决策者往往都并不是最懂得数据库的人，往往是懂一点数据库的企业IT主管或者软件开发团队的主管，因此在大多数情况下，我们其实不必纠结于是否选择了最好的数据库，而需要更多的去考虑如何用好已经选择的数据库。

以我对这两种数据库的浅薄理解来看，myql是一种十分简单的数据库，企业选择mysql可以简化今后数据库运维的工作。使用Mysql数据库只需要设计好部署架构，考虑清楚高可用、灾备、历史数据归档等方面的问题，初始化调整好参数，基本上后续只需要关注一下容量问题，SQL的性能问题，其他问题不需要过多的去考虑了。对于做惯了Oracle DBA的人来说，可能会觉得这个数据库简直是太简单了，想认真的去管理它都有点难。

不过正是因为其简单，因此对于选择了Mysql数据库的企业来说，有些问题就不能总是交给数据库去完成，应用开发需要更为小心。网上到处可以找到的阿里巴巴或者淘宝的Mysql应用开发军规实际上是企业在这些年MYSQL应用中的一些经验的总结，是十分值得我们去关注的。因为简单，所以Mysql的CBO优化器在功能上是与Oracle是无法相比的，开发Mysql应用的时候，SQL不能很任性的随便写，对研发团队的SQL编写制定一些企业军规是十分必要的。作为Oracle DBA在SQL优化工作中最常见的问题就是应该使用HASH JOIN的SQL 莫名其妙的使用了NESTED LOOP，导致SQL变慢数十倍，严重的时候把数据库服务器的CPU都爆掉了。而8.0.18版本之前，Mysql是不支持Hash Join的，而现在Mysql支持的Hash Join仍然是比较初级的。因此在复杂的多张大表关联问题上，Mysql一直是个弱点。正是因为这个原因，阿里的军规里不允许在并发量很大的SQL中，对于两张大表写关联语句。当然Mysql的CBO优化器也在不断地强大，我想今后这个问题也会逐渐被解决掉，在支持了Hash join之后，阿里这条军规也不一定就必须执行了。不过在hash Join上地缺点确实让Mysql在处理复杂查询地性能上落后于其他数据库，如果你地应用中有大量的复杂关系的多张大表的关联查询，那么你就需要慎重了。

PostgreSQL在开源数据库中虽然起了个大早，但是赶了个晚集。不过这些年，PG是越来越热了，不过无论怎样，其热度和Myql比起来还是有一定的差距，在db engine的排行榜上，PG的得分不足Mysql的一半，而且似乎最近又有拉大的迹象。这并不说明PG不如Mysql，事实上，PG在整体架构上与Mysql相比，还是有一定的优势的。其可扩展性很强，基础版本的功能也比Mysql更为全面。那么为什么PG技术上不比Mysql差，但是流行度有这么大的差距呢？一方面是因为互联网企业前些年大规模使用Mysql让Mysql的热度大增，另外一方面是PG本身的。因为PG在技术上很强大，因此PG很复杂，这导致使用PG的门槛远高于Mysql，要想用好PG也比用好MYSQL要更难一些。最近我发现很多Oracle的DBA没有转向MYSQL，而是纷纷转向PG了，估计也是看到PG的复杂性，想在PG运维中分一杯羹吧。

事实上，数据库选型是一个十分复杂的系统工程，绝对不是我这篇一千多字的文章所能说的清楚的。其实最后我要表达的一个观点就是，数据库选型往往不是最关键的问题，有时候你对此也无能为力，而如何用好数据库才关键。无论你选择PG还是MYSQL，都不会犯什么错误，那你只要考虑如何根据其特点去使用好它就行了。无论是1989年起步的PG还是1995年起步的MYSQL，在发展历史上和商业投入上都是无法与Oracle这样的商用数据库相比的，因此我们千万不要指望能在很短的时间里，这些数据库能够秒杀Oracle，我们首先要做的，是从应用开发入手，去优化我们的应用，让应用不会成为数据库杀手。