前言

在实际开发过程中,统计一个表的数据量是经常遇到的需求,用来统计数据库表的行数都会使用COUNT(*),COUNT(1)或者COUNT(字段),但是表中的记录越来越多,使用COUNT(*)也会变得越来越慢,本文我们就来分析一下COUNT的性能到底如何。

1.COUNT(1)、COUNT(*)与COUNT(字段)哪个更快?

执行效果:

COUNT(*)​MySQL 对COUNT(*)​进行了优化,COUNT(*)直接扫描主键索引记录,并不会把全部字段取出来,直接按行累加。COUNT(1)InnoDB引擎遍历整张表,但不取值,server 层对于返回的每一行,放一个数字“1”进去,按行累加。COUNT(字段)如果这个“字段”是定义为NOT NULL,那么InnoDB 引擎会一行行地从记录里面读出这个字段,server 层判断不能为NULL,按行累加;如果这个“字段”定义允许为NULL,那么InnoDB 引擎会一行行地从记录里面读出这个字段,然后把值取出来再判断一下,不是 NULL才累加。

实验分析

本文测试使用的环境:
[root@zhyno1~]# cat/etc/system-releaseCentOSLinuxrelease7.9.2009 (Core)[root@zhyno1~]# uname-aLinuxzhyno13.10.0-1160.62.1.el7.x86_64#1SMPTueApr516:57:59UTC2022x86_64x86_64x86_64GNU/Linux
测试数据库采用的是(存储引擎采用InnoDB,其它参数默认):
(MonJul2509:41:392022)[root@GreatSQL][(none)]>selectversion();+-----------+|version() |+-----------+|8.0.25-16|+-----------+1rowinset (0.00sec)

实验开始:

#首先我们创建一个实验表CREATETABLEtest_count (`id`int(10) NOTNULLAUTO_INCREMENTPRIMARYKEY,`name`varchar(20) NOTNULL,`salary`int(1) NOTNULL,KEY`idx_salary` (`salary`)) ENGINE=InnoDBDEFAULTCHARSET=utf8;#插入1000W条数据DELIMITER//CREATEPROCEDUREinsert_1000w()BEGINDECLAREiINT;SETi=1;WHILEi<=10000000DOINSERTINTOtest_count(name,salary) VALUES('KAiTO',1);SETi=i+1;ENDWHILE;END//DELIMITER ;#执行存储过程callinsert_1000w();

接下来我们分别来实验一下:

COUNT(1)花费了4.19秒
(SatJul2322:56:042022)[root@GreatSQL][test]>selectcount(1) fromtest_count;+----------+|count(1) |+----------+|10000000|+----------+1rowinset (4.19sec)
COUNT(*)花费了4.16秒
(SatJul2322:57:412022)[root@GreatSQL][test]>selectcount(*) fromtest_count;+----------+|count(*) |+----------+|10000000|+----------+1rowinset (4.16sec)
COUNT(字段)花费了4.23秒
(SatJul2322:58:562022)[root@GreatSQL][test]>selectcount(id) fromtest_count;+-----------+|count(id) |+-----------+|10000000|+-----------+1rowinset (4.23sec)

我们可以再来测试一下执行计划

COUNT(*)
(SatJul2322:59:162022)[root@GreatSQL][test]>explainselectcount(*) fromtest_count;+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+|id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra|+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+|1|SIMPLE|test_count|NULL|index|NULL|idx_salary|4|NULL|9980612|100.00|Usingindex|+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+1rowinset, 1warning (0.01sec)(SatJul2322:59:482022)[root@GreatSQL][test]>showwarnings;+-------+------+-----------------------------------------------------------------------+|Level|Code|Message|+-------+------+-----------------------------------------------------------------------+|Note|1003|/* select#1 */selectcount(0) AS`count(*)`from`test`.`test_count`|+-------+------+-----------------------------------------------------------------------+1rowinset (0.00sec)
COUNT(1)
(SatJul2323:12:452022)[root@GreatSQL][test]>explainselectcount(1) fromtest_count;+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+|id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra|+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+|1|SIMPLE|test_count|NULL|index|NULL|idx_salary|4|NULL|9980612|100.00|Usingindex|+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+1rowinset, 1warning (0.00sec)(SatJul2323:13:022022)[root@GreatSQL][test]>showwarnings;+-------+------+-----------------------------------------------------------------------+|Level|Code|Message|+-------+------+-----------------------------------------------------------------------+|Note|1003|/* select#1 */selectcount(1) AS`count(1)`from`test`.`test_count`|+-------+------+-----------------------------------------------------------------------+1rowinset (0.00sec)
COUNT(字段)
(SatJul2323:13:142022)[root@GreatSQL][test]>explainselectcount(id) fromtest_count;+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+|id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra|+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+|1|SIMPLE|test_count|NULL|index|NULL|idx_salary|4|NULL|9980612|100.00|Usingindex|+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+1rowinset, 1warning (0.00sec)(SatJul2323:13:292022)[root@GreatSQL][test]>showwarnings;+-------+------+-----------------------------------------------------------------------------------------------+|Level|Code|Message|+-------+------+-----------------------------------------------------------------------------------------------+|Note|1003|/* select#1 */selectcount(`test`.`test_count`.`id`) AS`count(id)`from`test`.`test_count`|+-------+------+-----------------------------------------------------------------------------------------------+1rowinset (0.00sec)

需要注意的是COUNT里如果是非主键字段的话

(TueJul2614:01:572022)[root@GreatSQL][test]>explainselectcount(name) fromtest_countwhereid<100 ;+----+-------------+------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+|id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra|+----+-------------+------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+|1|SIMPLE|test_count|NULL|range|PRIMARY|PRIMARY|4|NULL|99|100.00|Usingwhere|+----+-------------+------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+1rowinset, 1warning (0.00sec)

实验结果

    从上面的实验我们可以得出,COUNT(*)​和COUNT(1)​是最快的,其次是COUNT(id)。COUNT(*)​被MySQL查询优化器改写成了COUNT(0),并选择了idx_salary索引。COUNT(1)​和COUNT(id)都选择了idx_salary索引。

实验结论

总结:COUNT(*)=COUNT(1)>COUNT(id)

MySQL的官方文档也有说过:

InnoDB handles SELECT COUNT(*) and SELECT COUNT(1) operations in the same way. There is no performance difference

翻译: InnoDB以相同的方式处理SELECT COUNT(*)和SELECT COUNT(1)操作。没有性能差异

所以说明了对于COUNT(1)或者是COUNT(*),MySQL的优化其实是完全一样的,没有存在没有性能的差异。

但是建议使用COUNT(*),因为这是MySQL92定义的标准统计行数的语法。

2.COUNT(*)与TABLES_ROWS

在InnoDB中,MySQL数据库每个表占用的空间、表记录的行数可以打开MySQL的information_schema数据库。在该库中有一个TABLES表,这个表主要字段分别是:

TABLE_SCHEMA : 数据库名TABLE_NAME:表名ENGINE:所使用的存储引擎TABLES_ROWS:记录数DATA_LENGTH:数据大小INDEX_LENGTH:索引大小

TABLE_ROWS用于显示这个表当前有多少行,这个命令执行挺快的,那这个TABLE_ROWS能代替COUNT(*)吗?

我们用TABLES_ROWS查询一下表记录条数

(SatJul2323:15:142022)[root@GreatSQL][test]>SELECTTABLE_ROWS->FROMINFORMATION_SCHEMA.TABLES->WHERETABLE_NAME='test_count';+------------+|TABLE_ROWS|+------------+|9980612|+------------+1rowinset (0.03sec)

可以看到,记录的条数并不准确,因为InnoDB引擎下TABLES_ROWS行计数仅是大概估计值。

3.COUNT(*)是怎么样执行的?

首先要明确的是,MySQL有多种不同引擎,在不同的引擎中,COUNT(*)有不同的实现方式,本文主要介绍的是在InnoDB引擎上的执行流程

在InnoDB存储引擎中,COUNT(*)函数是先从内存中读取表中的数据到内存缓冲区,然后扫描全表获得行记录数的。简单来说就是全表扫描,一个循环解决问题,循环内: 先读取一行,再决定该行是否计入COUNT,循环内是一行一行进行计数处理的。

在MyISAM引擎中是把一个表的总行数存在了磁盘上,因此执行COUNT(*)的时候会直接返回这个数,效率很高。

之所以InnoDB 不跟 MyISAM一样把数字存起来,是因为即使是在同一个时刻的多个查询,由于多版本并发控制(MVCC)的原因,InnoDB表应该返回多少行也是不确定的。而且不论是在事务支持、并发能力还是在数据安全方面,InnoDB都优于MyISAM。

虽然如此,InnoDB对于COUNT(*)操作还是做了优化的。InnoDB是索引组织表,主键索引树的叶子节点是数据,而普通索引树的叶子节点是主键值。所以,普通索引树比主键索引树小很多。对于COUNT(*)这样的操作,遍历哪个索引树得到的结果逻辑上都是一样的。因此,MySQL 优化器会找到最小的那棵树来遍历。

需要注意的是我们在这篇文章里讨论的是没有过滤条件的COUNT(*),如果加了WHERE条件的话,MyISAM引擎的表也是不能返回得这么快的。

4.总结

COUNT(*)=COUNT(1)>COUNT(id)COUNT函数的用法,主要用于统计表行数。主要用法有COUNT(*)、COUNT(字段)和COUNT(1)因为COUNT(*)是SQL92定义的标准统计行数的语法,所以MySQL对他进行了很多优化,MyISAM中会直接把表的总行数单独记录下来供COUNT(*)查询,而InnoDB则会在扫表的时候选择最小的索引来降低成本。这些优化的前提是没有进行WHERE和GROUP的条件查询。在InnoDB中COUNT(*)和COUNT(1)实现上没有区别,而且效率一样,但是COUNT(字段)需要进行字段的非NULL判断,所以效率会低一些。因为COUNT(*)是SQL92定义的标准统计行数的语法,并且效率高,所以还是建议使用COUNT(*)查询表的行数。正如前面COUNT(name)的用例那样,在建表过程中需要根据业务需求建立性能较高的索引,同时也要注意避免建立不必要的索引。

最后多说一嘴,本文内容可能存在一些用例不够全面,如有不同见解。