单表数据破亿，MySQL vs PostgreSQL！

朦胧的锖色:
说一下个人拙见（如果不对欢迎指出）： 1.select count(*) from table(忘记up的表名是什么了。。。)，MySQL在没建索引的显示命中主键索引，原因是在没有主键的情况下，innodb会默认给表加一个隐藏列作为默认的主键。（MySQL对count（*）有优化，所以不要count（主键）啦，可能count（1）和count（*）性能差不多。。。） 2.MySQL和pg新建索引，MySQL比较用时感觉是因为MySQL这颗索引树保存了log_access_method的信息，数据较大，磁盘io用时就占大头了。 3.个人不熟悉pg，pg索引这么小感觉索引没有存log_access_method的数据，我觉得up可以新建完索引后select log_access_method from table 对比一下，因为MySQL索引树上有这个log_access_method的信息，说不定会更快。 4.希望up多一些其他sql的测试，比如order by啦，group啦，关联查询啦等等这些开发中常用的sql，对比一下这两个数据库的差异。 5.非常支持up的视频！ 6.我说的不对的还请大家指出，我是个工作时间不是很长的Java后端开发，可能有些说的不对，希望大家指出问题，多多交流。

【回复】好的，谢谢你的评论，后续我尽量多测试一些场景。 关于第三套，我稍微补充一下。 不论是mysql 还是 pg，默认索引都是btree+，节点会存储v_method这列的全部信息的。换句话说，btree+索引，是一种可逆的无损索引，也就是通过索引节点，就能反向算出来该列的原始值（pg里也有gist等有损索引存在的）。 之所以pg的索引大小这么小，我觉得最主要的原因是，pg13改进了对重复数据的优化，也就是重复值可以大幅缩小索引的磁盘占用，是一个非常好的改进思路，我忘记在视频里说了[呲牙]
【回复】up主使用的是myisan引擎，不是innodb
【回复】回复 @ArminFine :这个视频里的其实是innodb ；）
带头大哥199:
你的测试里面有一个不利于mysql的因素，就是主键是varchar uuid，mysql innodb引擎主键是聚集索引，原则上要求是越小越好，比如int类型，而且插入时还是要连续值效率才高，否则会导致不断的页分裂，当然你没测试插入就不说了，但确实把主键“搞大了”不小；而pg是堆表，天生没这个弱势

【回复】大哥，IM服务器用pg好，还是mango好呀
和谐之声:
个人说一下感想，oracle，mysql，postgresql DBA ，翻译了《mastering mariadb》（虽然没什么人看），oracle应该是性能最好的，用不起不要说人家不好，但是管理上确实是最复杂的，模块化感知不强，各种插件用起来超级复杂，光启动流程就有三种不同状态，牵一发动全身那种，各种功能相当齐全，基本上掌握了oracle，其他的数据库只是oracle的一个子集，可以说，好用，但不好管理。 pg各方面有点像oracle，或者说总是想去模仿oracle，但是能力有限又没法模仿太多，所以性能上比较接近oracle，管理起来非常容易，从安装就可以看出来了，属于下载bin文件直接能用那种。个人觉得pg应该是未来的方向（还有同宗的MPP GPDB），oracle那种功能强大的会有各种外挂模块解决，数据库可能只保留数据存储功能（pg，mysql那种感觉）。 至于mysql，嗨，真的是拉，innodb IOT的表天生注定了不能太大，各种管理上的缺点就不用说了，不过binlog可解析这一点还是不错的

【回复】回复 @xl7610 :这个迟早淘汰，关系型PG MYSQL未来方向。 NOSQL： MongoDB，HBASE。 Redis可以看做缓存数据库用吧
【回复】看看pg的历史，pg不想模仿oracle
【回复】回复 @xl7610 :不太了解，用过，很难用
kenkun2015:
数据库属于IO密集型应用，影响性能只会是磁盘，M1还是x86跑性能区别不大

【回复】看起来up的测试都没有用满磁盘的带宽，也许数据编码复杂度比较高，造成了CPU的瓶颈。
【回复】增加并发数，监控资源占用情况就能清楚了
大排泡饭:
强答，希望up能看到。 1，MySQL用主键索引count，一样要把整个表的数据读进来，因为主键b-tree叶子上存的不是地址，是数据。 2，如果b-tree叶子间有链接，io等于所有叶子block大小。 3，如果插入的值是随机的，叶子block会有空白，io会变大。 但是pg并发2个worker，速度没有x2倍，奇怪。

【回复】回复 @AndrewHZY :实测了一下，worker=1 /worker=2/worker=4 时间都是1分25秒左右，磁盘读取峰值都是460MB/s，不能再高了，不知道是什么原因达不到机器硬盘的峰值。总之磁盘访问速度确实一样，所以开多核也没啥改进喽。只能等下次测试一些需要cpu计算的再来看看区别啦。
【回复】mysql只有主键索引时，count慢，我理解跟你一样，因为时聚集索引，不是独立存在的，其实就在表里，所以要读整个表才行。后来加了一列v_method的索引，mysql规划器说利用上了，但是速度没变化，我感觉有点奇怪。 pg默认worker都是2，我并没有对比1和2的情况，所以你说没有看出来x2倍，我有点没听懂你的意思。
【回复】回复 @牧云踏歌 :给力，非常感谢！ 我信口开河，见笑了。
小太爷鬼畜记:
在从MySQL或者PostgreSQL中选一个的时候，数据量应该不存在大于一亿，更多的是几百万或者四五千万量级的数据，因为上亿数据更多会选用其他大数据数据库了。所以我认为对比几百万和几千万数据量，以及多种SQL查询或者一些连表更加适合这两者的选型参考。最后谢谢UP主这次对比测试[呲牙]

【回复】其实我们现在有多个千万到数亿级别数据量的项目，大部分场景都是无脑选择pg，保持技术栈的纯粹性和延续性是企业做技术选择时非常重要的考量，基于这种现实，我非常推荐pg，因为它大部分情况下的表现非常符合直觉，相反，mysql总在不知道什么时候遇即使借助官方文档都无法平滑解决的问题。
【回复】回复 @牧云踏歌 :最大的感受是~用pg~it's just work~很多功能不需要放应用层~pg直接出数~ 用mysql的话~为啥没这功能~为啥没那功能~应用层写一大堆~
【回复】回复 @星瞳今天吃左壬 :我个人想法是这样，不看数据库行数大不大，而是看磁盘容量占多少，如果容量才几十上百TB的磁盘。就应该优先考虑非分布式的解决方案。而且一定能找到合适的方案。 分布式的方案是给单机无法承载的情况下使用的。 再说分布式也不是银弹， 就像哲学家说的， 你得到了什么，同时，你也会失去什么。 如果早早明白自己“失去”什么，还好办，就怕后知后觉，等发现“失去”的无法弥补就晚了。
时光静好_勿思年华:
正在考虑新项目要不要换pg呢，感谢群主分享

【回复】回复 @super-小龙 :医院业务数据上百万条很正常
c0derVlog:
[呲牙]pg的话，如果真的国产化，也许会有更多好处

【回复】抄就抄，文化人就是不一样，国产化多好听
【回复】回复 @倚楼听风雨行 : 确实不要脸
活着为啥:
我的mySQL单表都有一亿6千万条数据了，最近对新数据进行了分表处理

【回复】回复 @江湖-小侠 :20万根本没必要分表。。以前机械硬盘应该是可以支撑500万的，现在企业级固态速度杠杠的
【回复】回复 @牧云踏歌 :1亿多数据，换啥数据库都得分表吧，不分确认不会炸吗
sjfinhe:
up问你个别的问题，你m1能打lol那期视频装的是哪个arm，21277还是别的？感谢

【回复】他那会用的是20231。其实20279以及以前的都可以。很多游戏和图形软件暂时运行不了的问题出在21277那个版本的64位DX11转译还有些问题，如果可以切换成32位DX9就正常了。最新的21292我还没尝试过。
【回复】回复 @黑貓的野望 :[给心心]
lidawei010:
很高兴能看到这样的测试和对比分析研究。为up主点赞。另外提两个小小的想法权当大家互通有无吧： 1、虽然许多软件项目的数据库数据量单表在百万级的多，千万级的相对少，但是考虑我接触过的项目，我认为考虑5000万级以上的分析研究是有意义的，为什么呢？道理很简单，如果这个项目的中标价是20万，无论你数据量多大，我就一个单点数据库给你搞了就行了，如果这个项目的中标价是1000万，那我就上真正的大数据平台了。对于前者而言，为了避免后期维护的成本太高代价太大，按照up主的分析，用PG肯定是优于MySQL的，5000万数据他也能跑，1个亿的时候，追加资金升级服务的时候我的技术成本和代价估计也不会那么大。总之，这是一个商业问题和业务问题和技术问题的综合考量。 2、我接触PG数据库并不多，但是深刻地感觉到他的好用，只是国内用的人相对还是少了一点，这需要我辈共同努力呀。TiDB也不错，但是那是个重型武器，众多的屌丝公司玩不起。所以，让我们共同努力，推动PG的普及和更广泛的应用。

烂尾楼苦主:
本来想说点啥的，看了一圈评论，大神太多啦[喜极而泣][喜极而泣][喜极而泣]把我想说的话吓回去了

笑微xiaowei:
type里的index 和 all 都是全表扫描，一个扫的二级索引，一个扫的聚簇索引。可以参考官方文档，有详细解释。

penguogui:
为什么主键用guid，这样对聚集索引影响比较大

【回复】回复 @penguogui :聚集索引在某些场景下有优势，但是这个场景太少了，所以我不喜欢它，毕竟有聚集索引是有代价了，insert性能受影响太大。 但是如果只看查询的话，有聚集索引，也不会拖后腿，最多是没发挥出来嘛。 所以我用有聚集索引的mysql 跟 没聚集索引的pg做select 的对比，肯定不是欺负mysql啦，相反，还是让了mysql一招半式，只是聚集索引想发挥优势的场景太少，在我测试的场景里，没体现出任何优势。
【回复】postgres没有聚集索引，嘿嘿，顺便说下，我也不喜欢聚集索引，毕竟业务查询的时候，很少正好按照主键作为唯一维度获取一段连续数据。
【回复】主键尽量不要容易被猜测
萨满的法杖:
1.count(*)mysql会有回表。 2.如果mysql记录很多，请注意索引的大小，b树的层太多还是很花时间去找数据的…

【回复】回复 @无敌刘老爷 :对啊，回什么表啊
【回复】count(*)为什么会回表呢？不需要任何数据啊