mysql qps_终于等到你——MySQL 5.7与PostgreSQL 9.6的百万QPS大比拼

MySQL与PG(PostgreSQL)谁的性能更强是一个很有意思的话题，知乎上的回答貌似都在说PG能将MySQL远远的甩在身后，甚至有些回答的同学还给出了性能测试的截图。

就区区看到的回答来看，测试的方法基本都很业余。2015年做过MySQL与PostgreSQL的测试对比：MySQL PK PostgreSQL，不服，跑个分呗(第一季)但是由于后续测试服务器被借调，因此未能完成后续的测试。

不过社区有人完成了这样的测试，而且找了MySQL与PG领域最为顶级的专家来进行调优，测试结果应该说非常具有公信力。需要说明的是，这个测试数据全部缓存在内存，测试服务器4 CPU、72Core、HT，一共144逻辑核。同学们可以将这个测试看成这两个数据库的最大性能，也可以观察这两个数据库在扩展性方面的对比。

好了，不多说，直接放上MySQL 5.7 vs PostgreSQL 9.6的测试结果。

测试采用sybench的测试模型，首先看根据主键进行查询的SELECT测试：

图中MySQL-5.7 Dimitri表示官方MySQL数据库，MySQL-5.7 Sveta使用的是Percona MySQL 5.7.15版本。从上图来看MySQL 5.7对比官方版本PG 9.6在性能上要好非常多，QPS可达160万，PG 最高140万。在并发100个线程后，官方PG的性能下降比较明显。

PG社区已定位问题所在，又是cache aligne所引发的，这个问题MySQL几年前已经发现，代码上也做了大量的优化。不过我们的程序员在开发时很少考虑这个问题，或许都对性能都不是很敏感。记得有一年网易校招的笔试题，我出了一题关于cache align的相关问题，可以说同学们几乎是全军覆没。

pgxact-algin就是打上patch后的PG性能，貌似打上补丁后PG性能得到了极大的提示。最高QPS可以有170W(但官方目前还没整合该patch，需要在其他场景下对此patch做进一步验证)。整体来看，在打上patch后，PG与MySQL在主键SELECT上不分轩轾。

对sysbench的RO(READ ONLY)测试来看，PG做的要比MySQL好，但是奇怪的是Percona版本比官方版本要差非常多。其实，这个测试结果有点出乎我的意料，因为range查询和ORDER BY这样的查询来看，索引组织表会更有优势。不过总体来看两者最大差距10%，基本还是一个水准，高并发下能达到100万QPS。

在sysbench的RW(读写)场景下，官方MySQL 5.7表现出了最好的性能，领先PG的幅度较大，超过4万 TPS(72万QPS)。async和trx=2表示允许事务非持久话，在生产上使用的可能性较小。

从最终测试来看，可以看出PG的性能并没有比MySQL好，在sysbench读写测试的场景下MySQL会更有优势。总体来看，两者在OLTP上的表现都非常棒，但MySQL在生态和互联网应用上的成熟度来看毫无疑问具有领导地位。

可以发现关系型数据库在全内存下的表现单实例已能超过150W QPS，即使读写也能达到72W QPS。而环顾四周，Redis和Memcached这类纯内存KV数据库似乎都无法达到这个高度。这是可能是一个有意思的话题，未来缓存怎么选择？用Redis还是MySQL Memcahced Plugin呢？前端的缓存速度还不如RDBMS？分布式呢？一个分布式集群QPS 100W？说不定一台MySQL又可以搞定了呢？

很多粉丝还没有养成阅读后点赞和转发的习惯，希望大家在阅读后顺便点赞与转发，以示鼓励！长期坚持原创真的很不容易，多次想放弃。坚持是一种信仰，专注是一种态度！