关于很多人说“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 大概是什么

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

[djangovcps]

我个人使用一般超过 2000 万条，就 g 了，除非表分区或者分表，另外说快的，可能是锁 id 查询快？

[RangerWolf]

@djangovcps 差不多，clickhouse 出来之前为了让 MySQL 的统计快一点我都愁死了

[djangovcps]

纯分析的要不试下 es ，蛮快的，一亿条 sum 应该 1s 内能搞定，如果内存 32G ，0.5s 内可以跑完

[j1132888093]

说快的肯定是指走了索引的情况，绝大多数业务都不会有扫描全表的场景，统计这种业务就不应该在 MySQL 中做

[zzNucker]

一亿条用索引都可能很慢啊。。。。

我也不知道轻松的标准是啥

[chendy]

隔壁帖子说的是
> 插入为主，简单的查询和统计

总量大，但是每次插的查的都是一小部分

楼主这种上来就全表扫一遍的，除非做缓存要不换啥都慢
顺便一说现在的机器性能真不错，早年这么大的表一个 count(*) 下去都要一会才能查出来

[RangerWolf]

@zzNucker 我也不知道，反正我看回复的贴子一堆说“轻轻松松”

[justkfc]

轻松主要的途径不就是索引和分区表

[awalkingman]

看了一下原来帖子的发言，大部份说的是简单查询下，我理解的简单查询就是走索引查询数据，没有 join 。mysql count 性能差不是什么冷知识，count ，sum 也算不上简单查询，计算列甚至可能用不上索引。
我理解楼主的情绪，但是发这个帖子的就显得有些没在点上了。

[Leviathann]

这不是典型的 olap 需求？所谓的轻轻松松都是基于 mysql 作为 oltp 数据库的前提

[june4]

你都搞全表扫描了，根本不是 mysql 的应用场景,mysql 追求的是尽可能走索引不扫表

[zzNucker]

@RangerWolf 看了原贴大概是单表 1 亿只按索引简单 select 吧，有需要聚合，计算就不用这个方案了

[iseki]

你自己都说了 ClickHouse 需要跑 12s 才能完成的全表求和，你觉得大家的“轻轻松松”能是什么标准呢？反正面对一亿行全表统计，我个人视能在分钟内完成就是可以忍受的，到底是不是轻轻松松要看需求，如果数据再大一点，能完成而不因为各种内存空间不足报错就是可以忍受的。

@zzNucker 他这是全表扫描，索引并不能提供太多价值。

[adoal]

因为，很久以前的说法是 MySQL 上了 2000 万就要分库分表……所谓轻松 1 亿是针对以前年代的硬件和 MySQL 版本上 OLTP 类系统哪怕做好索引和优化也扛不住这个量的数据来说的。

[liprais]

clickhouse 有事务么?

[akira]

mysql 上亿 只是说能用来做跑常规业务，汇总统计还是要别的来做的把

[night98]

你说这话不就是纯抬杠了吗，有哪个带事务的行数据库能扫一亿数据统计在十秒内出结果的？你光磁盘 io 都不够这个数吧。 不过也可以做，无非所有数据缓存到内存里，统计也还是很快的，加钱可达

[adoal]

刚才忽然好奇测试了一下 PostgreSQL ，在自己陈年老机上，i4-4460 ，32G 内存，没 tune 过参数的 PG16 ，生成了一亿条随机数，全表 sum 一下 1972.434 ms

[xiaofan2]

其实扫描速度跟你表设计大小有很大关系 我们有一个小表余额表 只保存了独立的几个余额相关字段 单表一亿扫描无任何问题

[min]

ap 场景用 tp 数据库，被 ap 库秒得渣也不剩