乐趣区

关于mysql:MySQL之COUNT性能到底如何

jiezi
  • GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。
  • GreatSQL 是 MySQL 的国产分支版本，应用上与 MySQL 统一。

前言

在理论开发过程中，统计一个表的数据量是常常遇到的需要，用来统计数据库表的行数都会应用 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
CentOS Linux release 7.9.2009 (Core)

[root@zhyno1 ~]# uname -a
Linux zhyno1 3.10.0-1160.62.1.el7.x86_64 #1 SMP Tue Apr 5 16:57:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
  • 测试数据库采纳的是（存储引擎采纳 InnoDB，其它参数默认）：
(Mon Jul 25 09:41:39 2022)[root@GreatSQL][(none)]>select version();
+-----------+
| version() |
+-----------+
| 8.0.25-16 |
+-----------+
1 row in set (0.00 sec)

试验开始：

# 首先咱们创立一个试验表

CREATE TABLE test_count (`id` int(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `name` varchar(20) NOT NULL,
  `salary` int(1) NOT NULL,
  KEY `idx_salary` (`salary`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

#插入 1000W 条数据
DELIMITER //
CREATE PROCEDURE insert_1000w()
BEGIN
    DECLARE i INT;
    SET i=1;
    WHILE i<=10000000 DO
        INSERT INTO test_count(name,salary) VALUES('KAiTO',1);
        SET i=i+1;
    END WHILE;
END//
DELIMITER ;

#执行存储过程
call insert_1000w();

接下来咱们别离来试验一下：

  • COUNT(1)破费了 4.19 秒
(Sat Jul 23 22:56:04 2022)[root@GreatSQL][test]>select count(1) from test_count;
+----------+
| count(1) |
+----------+
| 10000000 |
+----------+
1 row in set (4.19 sec)
  • COUNT(*)破费了 4.16 秒
(Sat Jul 23 22:57:41 2022)[root@GreatSQL][test]>select count(*) from test_count;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (4.16 sec)
  • COUNT(字段)破费了 4.23 秒
(Sat Jul 23 22:58:56 2022)[root@GreatSQL][test]>select count(id) from test_count;
+-----------+
| count(id) |
+-----------+
|  10000000 |
+-----------+
1 row in set (4.23 sec)

咱们能够再来测试一下执行打算

  • COUNT(*)
(Sat Jul 23 22:59:16 2022)[root@GreatSQL][test]>explain select count(*) from test_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 | Using index |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.01 sec)

(Sat Jul 23 22:59:48 2022)[root@GreatSQL][test]>show warnings;
+-------+------+-----------------------------------------------------------------------+
| Level | Code | Message                                                               |
+-------+------+-----------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select count(0) AS `count(*)` from `test`.`test_count` |
+-------+------+-----------------------------------------------------------------------+
1 row in set (0.00 sec)
  • COUNT(1)
(Sat Jul 23 23:12:45 2022)[root@GreatSQL][test]>explain select count(1) from test_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 | Using index |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

(Sat Jul 23 23:13:02 2022)[root@GreatSQL][test]>show warnings;
+-------+------+-----------------------------------------------------------------------+
| Level | Code | Message                                                               |
+-------+------+-----------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select count(1) AS `count(1)` from `test`.`test_count` |
+-------+------+-----------------------------------------------------------------------+
1 row in set (0.00 sec)
  • COUNT(字段)
(Sat Jul 23 23:13:14 2022)[root@GreatSQL][test]>explain select count(id) from test_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 | Using index |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

(Sat Jul 23 23:13:29 2022)[root@GreatSQL][test]>show warnings;
+-------+------+-----------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                       |
+-------+------+-----------------------------------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select count(`test`.`test_count`.`id`) AS `count(id)` from `test`.`test_count` |
+-------+------+-----------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

须要留神的是 COUNT 里如果是非主键字段的话

(Tue Jul 26 14:01:57 2022)[root@GreatSQL][test]>explain select count(name) from test_count where id <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 | Using where |
+----+-------------+------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

试验后果

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 查问一下表记录条数

(Sat Jul 23 23:15:14 2022)[root@GreatSQL][test]>SELECT TABLE_ROWS
    -> FROM INFORMATION_SCHEMA.TABLES
    -> WHERE TABLE_NAME = 'test_count';
+------------+
| TABLE_ROWS |
+------------+
|    9980612 |
+------------+
1 row in set (0.03 sec)

能够看到，记录的条数并不精确，因为 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. 总结

  • 1.COUNT(*)=COUNT(1)>COUNT(id)
  • 2.COUNT 函数的用法，次要用于统计表行数。次要用法有 COUNT(*)、COUNT(字段) 和 COUNT(1)
  • 3. 因为 COUNT(*) 是 SQL92 定义的规范统计行数的语法，所以 MySQL 对他进行了很多优化，MyISAM 中会间接把表的总行数独自记录下来供 COUNT(*) 查问，而 InnoDB 则会在扫表的时候抉择最小的索引来降低成本。这些优化的前提是没有进行 WHERE 和 GROUP 的条件查问。
  • 4. 在 InnoDB 中 COUNT(*) 和COUNT(1)实现上没有区别，而且效率一样，然而 COUNT(字段) 须要进行字段的非 NULL 判断，所以效率会低一些。
  • 5. 因为 COUNT(*) 是 SQL92 定义的规范统计行数的语法，并且效率高，所以还是倡议应用 COUNT(*) 查问表的行数。
  • 6. 正如后面 COUNT(name) 的用例那样，在建表过程中须要依据业务需要建设性能较高的索引，同时也要留神防止建设不必要的索引。

最初多说一嘴，本文内容可能存在一些用例不够全面，如有不同见解，欢送后盾留言探讨。

Enjoy GreatSQL :)

文章举荐：

面向金融级利用的 GreatSQL 正式开源
https://mp.weixin.qq.com/s/cI…

Changes in GreatSQL 8.0.25 (2021-8-18)
https://mp.weixin.qq.com/s/qc…

MGR 及 GreatSQL 资源汇总
https://mp.weixin.qq.com/s/qX…

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6…

在 Linux 下源码编译装置 GreatSQL/MySQL
https://mp.weixin.qq.com/s/WZ…

## 对于 GreatSQL

GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。

Gitee:

https://gitee.com/GreatSQL/Gr…

GitHub:

https://github.com/GreatSQL/G…

Bilibili：

https://space.bilibili.com/13…

微信 &QQ 群：

可搜寻增加 GreatSQL 社区助手 微信好友，发送验证信息“加群”退出 GreatSQL/MGR 交换微信群

QQ 群：533341697

微信小助手：wanlidbc

退出移动版