关于 mysql count 太慢的问题

[chenqh]

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

有什么办法提升没有?

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

求指点

我刚刚想了一个估计的方法

假如 where 为 A

添加两条 sql, 1. select * from table A order by id limit 5, 取到 min_id

2. select * from table A order by id desc limit 5, 取到 max_id

当然要考虑可能 table 为空的情况

通过 delta=max_id-min_id,如果 detlta < 10000,再直接查 count, 如果> 10000,直接返回 10000,不知道这个样子可不可以

我刚刚想了一个估计的方法

假如 where 为 A

添加两条 sql, 1. select id from table A order by id limit 5, 取到 min_id

2. select id from table A order by id desc limit 5, 取到 max_id

当然要考虑可能 table 为空的情况

通过 delta=max_id-min_id,如果 detlta < 10000,再直接查 count, 如果> 10000,直接返回 10000,不知道这个样子可不可以

[xupefei]

用 where 的列做 partition

[mejee]

没有索引吗

[lmshl]

做不到的，实际上现代数据库也没有在精确 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]

@lmshl 只有学刚刚下面那个 5KW 那个了,只展示一个日期范围内的数据,不让他选全部,不然太卡了

网上搜了一下,pg 的 count 比 mysql 还慢

[chenqh]

但是如果两个月的数据还是太大,到了 200W 怎么办?

[edis0n0]

35 单位是毫秒吗，毫秒我业务能接受，因为只有后台需要 count 大量数据

[chenqh]

@edis0n0 3S 是 3 秒的意思,35MS 我就不怕了咯

[edis0n0]

@chenqh #7 s 我看成 5 了

[mazyi]

百万的级别，大概率是 where 条件的问题和索引的问题吧，查真实数据也会很慢吧

[signalas1]

换 PG ，要不就是分析加索引

[chenqh]

@signalas1 网上搜的,pg 的 count 比 mysql 要慢

[olaloong]

同坑，mysql 算是快的了，mongodb 更是慢得炸裂。最后放弃精确计数了

[xy90321]

对实时性要求有多高？不高的话另外维护一个件数的值，后台定期更新就好了。

[chenqh]

@xy90321 管理后台,table 的那个 count

[makelove]

这么大数据量谁会实时计算 count ，编程是省心了，可是理论上做不到不遍历
要精确值又要速度只能手动维护一堆计数器，在记录增加时给相关计数器也加一

[dzdh]

count 目的是分页吗。

如果是，前端固定写死 100 页。

[kiwi95]

用户量大的系统一般会有一个单独的 counter 服务来处理各种计数

[oceanthe1h]

MyISAM

[signalas1]

@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]

如果不要求精确的话可以用 explain select * from table

[cp19890714]

首先需求是否合理？百万数据，精确 count 意义是什么？
我从来没有找到有哪种场景真的有这个需求。

如果是为了分页， 那么可以做个假 total ，只要 currentPageSize 大于或等于 pageSize ，就认为可能有下一页，returnTotal = pageNo * pageSize + 1. 用户就可以一直点下一页，直到最后一页。

如果是为了看大概的数据量，那么可以定时任务跑，根据条件(例如时间段)分多次查询，最后相加，放缓存。

用户需要知道精确 count 时，数据量一定是小的。
数据量大的时候，用户一定不需要知道精确 count 。

[mythabc]

用 flink 做实时 count ，结果实时写入 kafka

[zoharSoul]

@lmshl #3 索引概率分布估算一个值
大佬可以讲下 mysql 怎么估算这个值吗?

[dobelee]

无解的。可以做个简单的 cache ，一般很少人翻到最后一页，很多产品最后几页都不准，比如豆瓣。

[minsheng]

@lmshl 也不是完全不行，我之前看 CouchDB 的设计，它们的核心亮点就是可以对每个文档（这是个 NoSQL 的文档数据库）做持久化的 flat map + reduce ，就类似建立 index 一样把 map reduce 的结果存在硬盘上。用的是 B+树，把每个树的子节点的 reduce 结果都会存在 B+树的分支节点上，这样可以快速的（指数级复杂度）对连续区间的数据进行 reduce ，这就包括了题主的问题。

[minsheng]

我又想了一下，如果不需要 filter 的话，即每次只支持查询时间 a 到 b 之间的全部数据，数据的时间戳是单调递增的话，或许也不是不能用我说的这个树这样的想法？

手机打字，我就边打边算了。假设两个月生成两百万数据，那么一天在三万左右，每分钟 24 个。那可不可以每分钟跑个程序，统计一下那个分钟有多少数据，然后每三十分钟请求一下，刚刚三十分钟分钟有多少数据。注意你这个时候就可以直接加过去三十分钟已经算好的三十行了。然后依次类推，九百分钟一个单元，两万七千分钟一个单元（十八点七五天），这样这颗树不会很高。

查询的时候，你就把时间切成这样的区间，比如说查询 3min 到 180min ，你就把 30 、60 、90 、120 、150 这五行取出来加一下，再把 3 到 29 这二十多行加一下，最后累加就好了。

[xuanbg]

其实不精确的 count 也很难的。。。难就难在某个条件可能 count 很小，换个条件就很大。譬如订单状态，你查已完成订单，数量就大得不得了；待付款的总是很少。。。如果你查的是已完成，那查起来很慢，但没有出结果前你不能确定他慢啊。等你知道慢，结果也出来了，还优化个毛线啊。

[jhdxr]

虽然我也完全赞同大数据情况下还得精确统计这种需求的合理性在哪的问题，
但 200W 的 count 要 3s+，我觉得可以看看用的是 SSD 还是机械硬盘，还有就是索引的利用情况。

[route]

要是是有限的几条语句，就每隔时间间隔去执行语句，再存到缓存中，下次用直接拿出来就好了

[nicoljiang]

@chenqh 我 pg count 1000 万数据只需要 500ms ，没有什么索引。跟 pg 比起来，MySQL 都不算合格的数据库。

[chenqh]

@nicoljiang 不会吧,网上这个链接 https://dba.stackexchange.com/questions/149729/mysql-vs-postgresql-benchmarking-count-execution-speed

说的 pg count 比 mysql 慢啊

[chenqh]

@jhdxr 我虚拟机测的,200W COUNT 是没加条件的,我虚拟机是装在 SSD 上面的,但是问题是可能会加条件,这个页面就是管理后后的一个列表页面,上面一堆输入堆,下面一个 table

[Maxwe11]

mysql 本身也不适合干这个活儿；

如果你是生产库，那更不适合干这个，没事儿总 count 容易挂；

看你的延迟需求，是不是说一定要实时 count ，还是准实时，对于这类聚合，如果不是要求绝对实时，踏踏实实另搭个 clickhouse ，你再加个 0 也是秒出

[nicoljiang]

@chenqh pg 的 很多函数比 MySQL 快非常多，MySQL 都是残血版。

[chenqh]

@nicoljiang 可惜我 pg 不会,现在也懒得去学了 pg 了,又不是自己当老板,学 PG 有什么用,老板叫用什么用什么咯

[ShuA1]

explain