MySQL 单表三千万条数据，怎么优化 count 查询？

[CodeXx]

innodb，20 来个字段，每天有几十万条数据插入，在不做分表的情况下，怎么优化查询？现在是 count 查询很慢，5s 左右，带上查询条件比如近一个月就更慢了 10 多 s

[Joyboo]

分区，索引

[lidashuang]

可以不做 count，就不做
非做的话，看看能不能自己统计

或者放 es 里？

[CodeXx]

@Joyboo 索引对 count 查询貌似没用，还是得扫描全表

[CodeXx]

@lidashuang 分页查询用到的，也不知道会用什么条件查询

[huntcool001]

每天晚上把到零点的数据库的数据,离线做分析统计,count+各种查询条件等等(大概 es 或者其他框架,我不是很清楚), 结果存起来.

然后每天的数据,你有了当天零点以来的 binlog,就有了增量的 count. 和离线分析做出来的 count 结合起来.

大概是这个思路. 大厂都是这么干的.

[RickyC]

如果数据库不经常改变
根据查询条件建立几个 count 表, 里面保存根据各种条件得到的 count 数字;
并给 count 表建立索引

这样也许行

[RickyC]

接上
如果你每天还有 10w 的数据更改, 可以在每次更改的时候修改 count 表.

我觉得用 count 表可能解决你的问题. 预先统计

[egglin]

异构吧，es + mysql

[maigebaoer]

如果直接 count，用 count(*)吧，没啥特别好的建议。要不就直接入库前统计，写 count 字段。

[mrhhsg]

三千万的 count 那还不是一瞬间的事？加内存就完了

[v2orz]

插入的时候维护 count 信息？同 9L

[Leigg]

不要做实时查询即可，延迟个 30s 几分钟，数量到达一定高度后，多数场景中的实时统计就变成了一种伪需求，如果一定需要，换数据库，比如 clickhouse

[RangerWolf]

12 楼+1，clickhouse 的统计非常🐂

[dongisking]

这问题我这边也遇到过，特别是做管理后台特别多复杂的条件做 where 的 count 根本无法缓存，最后的解决办法是把 count 缓存，然后页面显示“大约 xx 条”，每一段时间更新一次

[cccy0]

近实时统计的话建议放 es

[sagaxu]

@CodeXx 索引 count 时有没有用，要看区分度，你索引类似性别这种低区分度的当然没用

[liuzhaowei55]

不要使用 count，如果是 id 自增而且没有删除数据可以使用最后一条数据的 id，或者使用 explain 返回的 rows，这个值不太准但响应很快

[nomansky]

加个表，里面保存 count，每插入一条数据更新 count

[haohappy]

count 慢 select 不慢吗

[dzdh]

@CodeXx 分页场景的话，where 排序字段 >上一页的最大值 limt x, n