一分钟带你了解：为什么MySQL的Count统计会越来越慢？

马龙网站制作公司哪家好，找创新互联！从网页设计、网站建设、微信开发、APP开发、响应式网站等网站项目制作，到程序开发，运营维护。创新互联从2013年开始到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联。

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

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

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

count函数的执行逻辑

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

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

select count(*) from t；

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

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

MySQL执行count的逻辑如下：

注意：这里虽然使用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(1)、count(主键)、count(非索引列)的性能差异。

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

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

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

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

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容