1. 树叶云首页
  2. 技术资讯

MySQL之COUNT性能到底如何？

管理••技术资讯

前言

在实际开发过程中，统计一个表的数据量是经常遇到的需求，用来统计数据库表的行数都会使用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-release
CentOSLinuxrelease7.9.2009 (Core)

[root@zhyno1~]# uname-a
Linuxzhyno13.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()
BEGIN
DECLAREiINT;
SETi=1;
WHILEi<=10000000DO
INSERTINTOtest_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)

实验结果

  1. 从上面的实验我们可以得出，COUNT(*)​和COUNT(1)​是最快的，其次是COUNT(id)。
  2. COUNT(*)​被MySQL查询优化器改写成了COUNT(0)，并选择了idx_salary索引。
  3. 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)的用例那样，在建表过程中需要根据业务需求建立性能较高的索引，同时也要注意避免建立不必要的索引。

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

文章来源网络，作者：管理，如若转载，请注明出处：https://shuyeidc.com/wp/294155.html<

赞 (0)
管理的头像管理
00
上一篇2025-05-20 23:01
下一篇 2025-05-20 23:02

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO，怎么选？技术资讯

    站群服务器和普通服务器到底哪个更适合GEO，怎么选？

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略，而普通服务器在单站点权威性和稳定性上更优，但2026年百度对内容质量的要求让两者选择更依赖业务模式，站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器，提供多个独立IP段（常为16、32或64个C段IP），每个IP绑定一个独……

    管理的头像管理
    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个，哪个更稳定？技术资讯

    物理服务器和云服务器做站群到底选哪个，哪个更稳定？

    做站群，物理服务器在核心指标上完全优于云服务器，尤其是对于追求稳定和长期排名的项目，物理服务器是唯一合理的选择，为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵，搜索引擎对IP关联性极其敏感，一旦检测到大量站点共享同一IP段或同一母机，惩罚风险会……

    管理的头像管理
    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱，怎么选？技术资讯

    国内高防服务器哪家防御真实靠谱，怎么选？

    国内高防服务器哪家防御真实靠谱？答案很明确：只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住，简米科技和酷番云就是这类代表，判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器，上来就问“你家多少G防御”，但数字背后水分很大，要判断防御是否真实,得看这三个方面：防御带宽是否独享？ 有些服务商宣……

    管理的头像管理
    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别？，怎么选？技术资讯

    裸金属服务器和物理服务器有什么区别？，怎么选？

    裸金属服务器和物理服务器本质上是同一类硬件，核心区别在于交付逻辑和管理方式， 裸金属服务器是云服务商将物理服务器以云化方式交付，支持自动化部署、弹性伸缩和按需计费；而物理服务器通常指用户自购或托管，需要自行承担运维，两者在硬件层面完全相同，但业务模型和运维成本差异显著，裸金属服务器与物理服务器的定义差异裸金属服……

    管理的头像管理
    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱，怎么选？技术资讯

    做GEO站群选哪家服务器服务商靠谱，怎么选？

    做SEO站群，选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证，成为众多站群运营者的首选，站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量，搜索引擎对站群的识别逻辑越来越严，如果IP段集中、或服务器存在违规记录，很……

    管理的头像管理
    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注