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

业务发展初期，为了功能的快速实现，遇到统计行数的需求时，我们一般都是简单的使用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(非索引列)。