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

2024-01-13 20:46:51 +08:00
 RangerWolf

在之前的一个帖子 https://ex.noerr.eu.org/t/1007852 的讨论引申出的另外一个话题

我说说我的环境：

统计 SQL:

select sum(cost)
from table_name

统计全表的 cost 字段的总和

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

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

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

12369 次点击
所在节点    数据库
85 条回复
djangovcps
2024-01-13 20:49:55 +08:00
我个人使用一般超过 2000 万条，就 g 了，除非表分区或者分表，另外说快的，可能是锁 id 查询快？
RangerWolf
2024-01-13 20:52:07 +08:00
@djangovcps 差不多，clickhouse 出来之前为了让 MySQL 的统计快一点我都愁死了
djangovcps
2024-01-13 20:55:49 +08:00
纯分析的要不试下 es ，蛮快的，一亿条 sum 应该 1s 内能搞定，如果内存 32G ，0.5s 内可以跑完
j1132888093
2024-01-13 21:05:39 +08:00
说快的肯定是指走了索引的情况，绝大多数业务都不会有扫描全表的场景，统计这种业务就不应该在 MySQL 中做
zzNucker
2024-01-13 21:08:47 +08:00
一亿条用索引都可能很慢啊。。。。

我也不知道轻松的标准是啥
chendy
2024-01-13 21:11:30 +08:00
隔壁帖子说的是
> 插入为主，简单的查询和统计

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

楼主这种上来就全表扫一遍的，除非做缓存要不换啥都慢
顺便一说现在的机器性能真不错，早年这么大的表一个 count(*) 下去都要一会才能查出来
RangerWolf
2024-01-13 21:11:39 +08:00
@zzNucker 我也不知道，反正我看回复的贴子一堆说“轻轻松松”
justkfc
2024-01-13 21:14:11 +08:00
轻松主要的途径不就是索引和分区表
awalkingman
2024-01-13 21:15:00 +08:00
看了一下原来帖子的发言，大部份说的是简单查询下，我理解的简单查询就是走索引查询数据，没有 join 。mysql count 性能差不是什么冷知识，count ，sum 也算不上简单查询，计算列甚至可能用不上索引。
我理解楼主的情绪，但是发这个帖子的就显得有些没在点上了。
Leviathann
2024-01-13 21:15:11 +08:00
这不是典型的 olap 需求？所谓的轻轻松松都是基于 mysql 作为 oltp 数据库的前提
june4
2024-01-13 21:17:45 +08:00
你都搞全表扫描了，根本不是 mysql 的应用场景,mysql 追求的是尽可能走索引不扫表
zzNucker
2024-01-13 21:22:00 +08:00
@RangerWolf 看了原贴大概是单表 1 亿只按索引简单 select 吧，有需要聚合，计算就不用这个方案了
iseki
2024-01-13 21:30:48 +08:00
你自己都说了 ClickHouse 需要跑 12s 才能完成的全表求和，你觉得大家的“轻轻松松”能是什么标准呢？反正面对一亿行全表统计，我个人视能在分钟内完成就是可以忍受的，到底是不是轻轻松松要看需求，如果数据再大一点，能完成而不因为各种内存空间不足报错就是可以忍受的。

@zzNucker 他这是全表扫描，索引并不能提供太多价值。
adoal
2024-01-13 22:06:19 +08:00
因为，很久以前的说法是 MySQL 上了 2000 万就要分库分表……所谓轻松 1 亿是针对以前年代的硬件和 MySQL 版本上 OLTP 类系统哪怕做好索引和优化也扛不住这个量的数据来说的。
F281M6Dh8DXpD1g2
2024-01-13 22:12:12 +08:00
clickhouse 有事务么?
akira
2024-01-13 23:10:33 +08:00
mysql 上亿 只是说能用来做跑常规业务，汇总统计还是要别的来做的把
night98
2024-01-13 23:39:36 +08:00
你说这话不就是纯抬杠了吗，有哪个带事务的行数据库能扫一亿数据统计在十秒内出结果的？你光磁盘 io 都不够这个数吧。 不过也可以做，无非所有数据缓存到内存里，统计也还是很快的，加钱可达
adoal
2024-01-13 23:59:46 +08:00
刚才忽然好奇测试了一下 PostgreSQL ，在自己陈年老机上，i4-4460 ，32G 内存，没 tune 过参数的 PG16 ，生成了一亿条随机数，全表 sum 一下 1972.434 ms
xiaofan2
2024-01-14 00:00:31 +08:00
其实扫描速度跟你表设计大小有很大关系 我们有一个小表余额表 只保存了独立的几个余额相关字段 单表一亿扫描无任何问题
min
2024-01-14 00:01:00 +08:00
ap 场景用 tp 数据库，被 ap 库秒得渣也不剩

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1008404

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX