MYSQL与PG为啥非要争个谁好谁坏呢？

原创白鳝白鳝的洞穴

2022年07月19日 05:56

MYSQL和PG是影响力最大的两个开源关系型数据库，这些年来围绕这二者谁更好的问题，一直是十分激烈的。目前的大多数创新的数据库产品和国产数据库产品都或多或少地与这两个数据库有些渊源。因此也具有把这两个数据库分出个高下来的动力。实际上不仅仅在国内，国外PG派和MYSQL派也经常吵得不可开交。根据database Journal的统计，PG数据库全球市场占有率大约为15%+，Mysql的全球市场占有率大约为44%+，在全球占有率方面Mysql绝对领先。不过在美国的最新统计，PG的市场占有率高达33%，反超了MYSQL的31%。我不知道这个数据是不是靠谱，实际上数据库市场占有率的国别差异也很大，在英国，MYSQL 以6.75%小幅度领先于PG的5.74%。和几年前的数据对比，虽然全球范围内MYSQL的市场占有率还远高于PG，不过二者的差距在逐渐缩小。

实际上数据库好坏之争已经几十年了，争来争去企业选择数据库产品最终还是要看应用场景、商务条件与企业的喜好或者说相关决策者的喜好。前两年在一家互联网金融公司，他们的CIO问我MYSQL和PG数据库，该如何选择。他们以前用MYSQL数据库，数据量大了以后，SQL编写就要十分小心，否则容易出现性能问题。而出现过性能问题的SQL语句，他们测试了一下，在PG上跑出来的性能还可以。因此他们公司内部就有些想把数据库换成PG的想法。

我分析了一下他们的应用场景，确实随着数据量的增加，一些多表关联的复杂查询会出现性能问题，就这一点来说，换PG数据库也说的过去。不过根据他们应用的特点、客户的运维能力以及他们售后服务的投入，再进行分析。我们最终得出了截然不同的答案，他们还是继续使用MYSQL，只是应用开发上设定一些开发规范，避免比较复杂的多表查询语句。因为他们销售的是套装软件，总体的研发成本会被大量的用户摊销，因此提高软件质量本身就是日常工作的重点。而他们的客户在运维方面的能力较弱，每个项目的经费也有限，较难提供比较丰富的支撑服务。使用MYSQL可以大幅度降低运维的复杂性，只要教会客户在系统有问题的时候杀死慢查询的会话，或者直接杀掉数据库进程，自动重启应用就可以解决大部分问题了。如果换成PG数据库，在运维方面将面临更大的复杂度，其成本远远高于在应用上加以优化。

实际上，PG数据库和MYSQL数据库从底层设计思想上是完全不同的，MYSQL数据库自从诞生以来就是一个简单易用的关系型数据库，用于一些数据规模不是很大，业务复杂度不是很复杂的厂家。随着这些年的发展，MYSQL已经发展出了10多种存储引擎，通过不同的存储引擎可以实现各种各样的业务场景。MYSQL本身就是一个和应用与应用开发结合的很紧密的数据库，受到开发人员的喜爱也并不意外。

而PG数据库是一个对象关系型数据库，是一款真正的从核心就是对象数据库的数据库产品。是比Oracle这种号称对象数据库，实际上只是在关系型数据库中加入了一些对象支持的数据库产品还正宗的对象数据库。正是因为如此，PG数据库略微复杂一些，支持更多的业务种类与开发模式。因此在各种功能支持上，PG数据库比MYSQL更为丰富一些，把Oracle上开发的应用系统迁移到PG上也更容易一些。不过因为PG数据库的复杂性，也导致了PG数据库的运维和调优也更为复杂一些。

虽然说二者的出厂默认参数设置的都不太合理，不过如果二者都用默认参数运行，PG数据库可能会跑的更流畅一些，因此有些人以此为依据进行测试对比，得到了PG数据库性能碾压MYSQL的结论，实际上这种比较是极不科学的。如果都是经过了充分调优，二者在相同的硬件配置下做TPMC压测，性能也是比较接近的。

回到选择数据库产品本身来说，我们可以根据自己的应用场景，研发团队的特点，运维团队的能力，企业以往的历史积累来选择项目所使用的数据库。如果你的开发人员能够写出质量比较好的SQL，那么选择MYSQL可能会对以后的长期运行有利。如果你的业务确实特别复杂，而开发团队的SQL又写得特别烂，那么就别硬撑着用MYSQL了，选PG可能以后会省心一些。

2012年的时候，和腾讯的朋友交流，那时候腾讯在一般的交易类应用里用MYSQL数据库，而在数据集市中使用PG。我那时候还主要在搞Oracle，对MYSQL/PG的特点不太了解。我就问他们，为什么这么选择，他们也说不出特别的道理，只是说他们公司的系统传统上都是用MYSQL，只是数据集市中经常有比较复杂的SQL语句，经过对比发现MYSQL性能不如PG，于是他们就在这个领域全部选择了PG。

继续滑动看下一个