图中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的幅度较大，超过40万 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又可以搞定了呢？
如果想要获得本次测试的完整介绍与Slide，可点击下方的{阅读原文}
长期坚持原创真的很不容易，多次想放弃。坚持是一种信仰，专注是一种态度！点赞是对作者最好的褒奖哟
