<返回更多

为什么MySQL的Count统计会越来越慢?

2023-03-10  今日头条  程序员拾山
加入收藏

业务发展初期,为了功能的快速实现,遇到统计行数的需求时,我们一般都是简单的使用count函数搞定。

但是有的小伙伴可能慢慢会发现,随着表中的数据越来越多,count统计数据的速度越来越慢,耗时也越来越长了。

今天带大家了解一下,为什么MySQL的count函数会越来越慢,count函数的实现逻辑是什么,以及如何解决大数据量下的统计需求?

count函数的执行逻辑

我们知道,MySQL分为Server层和引擎层,引擎大家基本使用的都是InnoDB,这里就不再重复强调了。

那对于下面这样一条sql,MySQL是如何执行的呢?

select count(*) from t;

由于我们并没有使用where条件,那么对于MySQL来说,从聚簇索引或二级索引来统计数据都是可以的。

并且普通的二级索引只存储了索引键以及主键,所以相对于聚簇索引来说,二级索引树会更矮更胖,MySQL会优先使用二级索引,以达到减少IO提升性能的目的。

MySQL执行count的逻辑如下:

  1. Server通过执行器调用InnoDB的查询接口,尝试获取第一条数据。
  2. InnoDB引擎在二级索引上找到第一条记录,并返回给Server层。

注意:这里虽然使用count(*)查询,但是并不需要到聚簇索引上回表,因为最终的目的是统计聚合后的行数,回表并没有什么意义。InnoDB会给Server返回一个常数0,表示这一行记录有效。

3.Server层收到常数0,并判断常数0不是null,认为返回值有效,会将统计值+1。

4.Server通过执行器调用InnoDB查询接口,获取下一条记录。

5.InnoDB顺着二级索引找下一条记录,继续返回常数0。

6.重复步骤3,4,5,直到将整棵二级索引树扫描完,最终将统计的结果发给客户端。

大家可以看到,MySQL在执行count函数时,会遍历某一个索引树,查询树上所有的记录进行累加统计。

随着表中的记录越来越多,索引树也会越来越高,越来越胖。

那么整个统计过程也会越来越耗时。

这就是为什么count函数会越来越慢的原因。

大数据量下的如何快速统计行数

这里有两个考虑的因素:绝对精准和允许误差。

如果在极大数据量下,允许有误差产生。那么我们可以提前维护一个变量count,通过记录表中的增删改操作,对这个变量做相应的加减。这样在获取行数时,只需要查询这个变量就可以快速获取结果了。

如果要求绝对精准,并且对性能要求也不太高,那么就继续使用count函数吧。不要觉得这个方法low,能满足业务的方法都是好方法。

如果对性能要求也很高,那么OLAP数据库可能会是一个好选择。

不同count函数的性能差异

经常有小伙伴纠结count(*)、count(1)、count(主键)、count(非索引列)的性能差异。

通过上文我们可以知道,使用count(*)时,InnoDB引擎返回的是常数0,那么自然count(1)返回的也是常数,这两个性能可以看做是一致的。

对于count(主键),由于二级索引树上直接保存着主键id,所以不会有回表的操作。由于InnoDB返回到Server的是主键id,而如果主键id又恰巧比较大,比如是一个较长的字符串时,性能会产生稍微的下滑。

对于count(非索引列),由于需要不停的回表,这种方式性能相对是非常差的,也是不推荐的一种做法。

按性能排序:count(*) ≈ count(1) > count(主键) > count(非索引列)。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>