关于 mysql count 太慢的问题

2022-10-06 18:51:35 +08:00
 chenqh

200W 的数据量,count(*)就要 3S 多了

有什么办法提升没有?

使用 cache?但是 count(*)的时候 where 并不是固定的

求指点

4439 次点击
所在节点    MySQL
36 条回复
xupefei
2022-10-06 18:57:07 +08:00
用 where 的列做 partition
mejee
2022-10-06 19:09:34 +08:00
没有索引吗
lmshl
2022-10-06 19:28:37 +08:00
做不到的,实际上现代数据库也没有在精确 count 上做很多努力,你看各大网站的搜索结果,基本上都是给你个估算值( 10000+),因为精确 count 是需要遍历所有 where 命中行并聚合计数的。

我在我公司应用上实现的 count 是这么个逻辑:
先用索引概率分布估算一个值,如果这个值小于 10k ,那么执行精确 select count(*) where ... 返回给前端。
如果这个值大于 10k ,那么将此估算值抹去末尾 N 位,返回给前端,前端显示为“约 53200+ 符合结果”

参考资料:
https://wiki.postgresql.org/wiki/Count_estimate
https://www.datastax.com/blog/counting-keys-cassandra
chenqh
2022-10-06 19:51:06 +08:00
@lmshl 只有学刚刚下面那个 5KW 那个了,只展示一个日期范围内的数据,不让他选全部,不然太卡了

网上搜了一下,pg 的 count 比 mysql 还慢
chenqh
2022-10-06 19:52:00 +08:00
但是如果两个月的数据还是太大,到了 200W 怎么办?
edis0n0
2022-10-06 19:52:37 +08:00
35 单位是毫秒吗,毫秒我业务能接受,因为只有后台需要 count 大量数据
chenqh
2022-10-06 19:54:43 +08:00
@edis0n0 3S 是 3 秒的意思,35MS 我就不怕了咯
edis0n0
2022-10-06 19:56:32 +08:00
@chenqh #7 s 我看成 5 了
mazyi
2022-10-06 20:18:45 +08:00
百万的级别,大概率是 where 条件的问题和索引的问题吧,查真实数据也会很慢吧
signalas1
2022-10-06 20:21:39 +08:00
换 PG ,要不就是分析加索引
chenqh
2022-10-06 20:22:06 +08:00
@signalas1 网上搜的,pg 的 count 比 mysql 要慢
olaloong
2022-10-06 20:23:27 +08:00
同坑,mysql 算是快的了,mongodb 更是慢得炸裂。最后放弃精确计数了
xy90321
2022-10-06 20:46:23 +08:00
对实时性要求有多高?不高的话另外维护一个件数的值,后台定期更新就好了。
chenqh
2022-10-06 20:56:45 +08:00
@xy90321 管理后台,table 的那个 count
makelove
2022-10-06 21:06:21 +08:00
这么大数据量谁会实时计算 count ,编程是省心了,可是理论上做不到不遍历
要精确值又要速度只能手动维护一堆计数器,在记录增加时给相关计数器也加一
dzdh
2022-10-06 22:10:47 +08:00
count 目的是分页吗。

如果是,前端固定写死 100 页。
kiwi95
2022-10-06 22:11:27 +08:00
用户量大的系统一般会有一个单独的 counter 服务来处理各种计数
oceanthe1h
2022-10-06 22:23:09 +08:00
MyISAM
signalas1
2022-10-06 22:33:37 +08:00
@chenqh Planned Count

To avoid the shortcomings of exact count, PostgREST can leverage PostgreSQL statistics and get a fairly accurate and fast count.

https://postgrest.org/en/v8.0/api.html#planned-count
kenvix
2022-10-06 22:36:33 +08:00
如果不要求精确的话可以用 explain select * from table

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

https://www.v2ex.com/t/884917

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

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

© 2021 V2EX