关于很多人说“MySQL 1 亿条数据统计轻轻松松”，确实超出我的认知。可以请各位大神发一下你们的“轻松”的标准跟扫描的数据量嘛？

[RangerWolf]

在之前的一个帖子 https://www.v2ex.com/t/1007852 的讨论引申出的另外一个话题

我说说我的环境：

• MySQL 8.x
• 数据量：9000W+ 条 （我的生产环境确实没有 1 亿+数据量的表）
• 扫描的数据量：全表
• 运行环境：AWS 的 t3.xlarge (4c 16G) 磁盘类型为 GP3

统计 SQL:

select sum(cost)
from table_name

统计全表的 cost 字段的总和

反正跑了 20s 是没有跑完的。相同的查询在 Clickhouse 跑了 12s （ clickhouse 的配置也不高，而且也是单机环境，非分布式）

想看看各位大神的环境与配置，以及统计的 SQL 大概是什么

如果各位的“轻松”的条件是用索引极大的减少了扫描的数据量，那感觉就不是一个话题了

[nuk]

所以 mysql 到底跑了多少秒

[ntedshen]

拿列式库在本地查单列。。。
拿行式库不允许索引不允许分布式还要放到 io 差了好几倍的 vps 上跑。。。
得出一个结论至少慢 60%。。。

讲道理，我认为这属于褒奖 mysql 。。。

gp3 的 16kio 是 16000 合 256MB/s 。。。
请注意现在的家用低端固态的 4k io 都能达到 160k 。。。

[est]

感觉这不是 mysql 的问题，而是 aws 的 IOPS 的锅？ LZ 测试 clickhouse 也是 t3.xlarge (4c 16G) 磁盘类型为 GP3 嘛？

mysql 的话，还得调优一下 InnoDB 才有比较好的性能。我 10 年前测 tokudb ，把 qq 那个 10 亿条导入进去，无聊 sum 了一下群号。。 差不多 10 秒就出来。。

[miniliuke]

求求了用 pg 吧，实测真的吊打 Mysql （未调优）......

[ShuWei]

别拿极端情况反驳，毕竟原贴的绝大部分情况下，都不太可能涉及全表扫描，而且，这种全表扫描，很多时候都可以通过冗余统计字段的方式来温柔对待，因地制宜就好，在需求和成本间实现优雅的平衡

[xmh51]

大哥，我们只是提建议，不是你用来抬杠的对手。
Clickhouse 没有完整的事务支持。 缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据，但这符合 GDPR 。Clickhouse 适合海量数据，低频更新，低并发查询。尤其是统计数据。
mysql 是一个传统的支持完整事务的数据库。
两者不在一个赛道上，根据自己的需要自己决策选型。

[LeeReamond]

听别人说有什么用，你每天混论坛的还不知道大部分人是啥水平。所谓轻松能跑出来就算轻松，一个查询 5 秒，只要用户没 call 过来说慢那就是纯正常响应速度。

楼上的也不知道有几个试过，一亿级数据就算用唯一索引，单行数据调取性能下降多少，a<索引<b 查询多长时间才能返回，分区后能不能加速。

反正我试完上述结论没一个显示能用的。
当然这是单实例，你集群虚拟化数据层当我没说。。

[mysunshinedreams]

之前工作经历有过单表上 10e 数据的，不过仅存了包含主键在内的四个字段，也是在不断往上探测系统极限性能的情况下才发现瓶颈的，某些特别场景还是可以抗住的。

[xxfye]

v2 的人谈数据库，基本上都是在赛博斗蛐蛐。

不会有人不知道 mysql 一个查询只能用单线程吧。
这也是为什么一群人吹嘘 oracle 大表连接很快，又有人吹嘘 pgsql 可以平替 oracle 的原因。
因为其他数据库的一个查询可以利用多个核来执行，mysql 还在煞笔的用一个核去跑，不慢才怪呢。

[fd9xr]

5.5 都随便跑…到底哪里不行了 是什么要让你在里面算 SUM()

[W3Cbox]

什么样的业务会有上亿数据。从事开发年 10 来，很多公司从创业到倒闭了都没有上亿数据，真有上亿数据，公司都可以上市了

[xuanbg]

3000 万+，6 表联查，平均 50ms 。

[wudaye]

@W3Cbox 根本不需要什么上市公司，只要用户量达到 1000w 的公司，核心业务表数据量上亿几乎是必然的事

[june4]

@LeeReamond 有索引还会慢？你要不要了解下索引的原理，走索引百亿内无论多少数据都只要固定的小量读硬盘次数。刚在我的亿级表上试了下，无论是取单行还是 100 行，在索引上耗时显示都是 0.000s

[goodryb]

查了下 aws GP3 的性能参数 每个卷的最大 IOPS (16 KiB I/O) 16,000 ， 每个卷的最大吞吐量 1,000 MiB/s

这个速度怕不是连我台式机上面的 pcie3.0 ssd 都打不过，对数据库好一点吧

https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-volume-types.html

[hhecoder]

@W3Cbox 很多数据类的 c 端产品，稍微有点成绩的上亿数据都轻轻松松。

[iseki]

@xxfye MySQL 8.x 还没有并行查询能力吗？有点弱啊

[xxfye]

@iseki innodb 存储引擎在 8.0.14 有过一次升级，支持并行读取了。
但执行器还是只能一个线程处理。
可以说 mysql 的并行查询能力聊胜于无。

[FishBear]

我们公司的表 12 亿了还在跑

[yh5DC6Y7u7TdcT9s]

oltp 场景： 典型代表 pg 和 mysql ，使用范围最广，常见 web 业务，日常增删改查，支持事务的 ACID 特性； 通常查一整行数据或者多列，基本不会全表扫描，所以数据底层按照行来存储数据，读一整行时按照局部性原理，会对缓存友好
olap 场景：典型代表 clickhouse ，doris ，hbase 等；常用于分析统计，需要大量扫描数据，且通常只关注某一列数据，不支持事务/支持的很弱，底层数据是按照列来存储的，因此扫描列的效率远大于扫描整行

两个不同的赛道， 底层设计都不一样