MySQL COUNT(*)性能原理与优化详解

Theo

发布时间：2026-10-15| 4人浏览过

原创

在统计数据库表行数时，开发人员常在 COUNT(*)、COUNT(1) 和 COUNT(字段) 之间选择。本文通过实验对比这三种写法在 InnoDB 引擎下的执行性能，解析 COUNT(*) 的底层索引扫描原理，并说明为何它是 SQL92 标准推荐的最佳实践。

1. COUNT(*)、COUNT(1) 与 COUNT(字段) 性能对比

在实际开发中，为了获取表的数据量，开发者通常使用 COUNT(*)、COUNT(1) 或 COUNT(具体字段)。很多人担心随着数据量增加，这些查询会变慢。实际上，它们的执行逻辑存在细微差别：

COUNT(*)：这是最常用的写法。InnoDB 引擎会对它进行特殊优化，直接扫描主键索引记录，但并不取出全部字段，而是按行累加计数。由于是索引组织表，它会选择体积最小的索引树进行遍历以降低 I/O 成本。
COUNT(1)：InnoDB 引擎会遍历整张表，但对于 Server 层返回的每一行，都会固定填入一个数字“1”，然后按行累加。其逻辑与 COUNT(*) 高度相似。
COUNT(字段)：如果该字段定义为 NOT NULL，InnoDB 会逐行读取该字段并累加；如果字段允许为 NULL，则需要在 Server 层额外判断该字段的值是否为 NULL，这增加了少许 CPU 开销。

第1步：构建测试环境与数据

为了验证上述理论，我们搭建如下测试环境：

操作系统：CentOS Linux release 7.9.2009 (Core)
数据库版本：GreatSQL (兼容 MySQL 8.0.25)，存储引擎为 InnoDB。

# 创建实验表，包含主键、普通字段及二级索引
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();

第2步：分别执行三种计数查询并计时

在包含千万级数据的表中，分别执行以下 SQL 语句观察耗时：

测试 COUNT(1)：

SELECT count(1) FROM test_count;
-- 结果：10000000 rows, Time: 4.19 sec

测试 COUNT(*)：

SELECT count(*) FROM test_count;
-- 结果：10000000 rows, Time: 4.16 sec

测试 COUNT(id)（非主键但无NULL字段）：

SELECT count(id) FROM test_count;
-- 结果：10000000 rows, Time: 4.23 sec

第3步：分析执行计划 (EXPLAIN)

查看上述语句的执行计划，发现三者表现惊人地一致。以 COUNT(*) 为例：

EXPLAIN SELECT count(*) FROM test_count;
-- Extra: Using index (表示使用了覆盖索引)
-- Key: idx_salary (选择了最小的二级索引而非主键聚簇索引)

虽然查询的是 count(*)，但在警告信息 (Show Warnings) 中可以看到 MySQL 优化器实际将其改写成了 count(0)：
select count(0) AS count(*) from test.test_count。这说明优化器认为统计所有行，无论填充什么常数（0、1）或 *，逻辑上都是计算行数。

2. 为什么建议使用 COUNT(*)？

从上面的测试结果来看：COUNT(*) ≈ COUNT(1) > COUNT(字段)。
InnoDB 内部处理 COUNT(*) 和 COUNT(1) 的方式完全相同，没有性能差异。但是，官方文档明确建议优先使用 COUNT(*)，原因有二：

语义清晰：符合 SQL-92 标准，明确表示“统计表中的总行数”。
易于维护：代码可读性高，避免让后来者误以为 “1” 是某个特定列的值。

注意：如果是 COUNT(允许为NULL的字段)，由于多了一步非空判断，理论上会比前两者稍慢一点点。

3. COUNT(*) 能否用 TABLES_ROWS 替代？

许多开发者试图通过查询系统表 information_schema.tables 中的 TABLE_ROWS 来快速获取行数，因为该查询通常在毫秒级完成。例如：

SELECT TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'test_count';
-- 结果可能显示：9980612（与实际 10000000 有偏差）

结论：不能替代。
在 InnoDB 引擎中，TABLE_ROWS 仅仅是一个预估统计值。由于 InnoDB 支持多版本并发控制（MVCC），不同事务在同一时刻看到的表数据量可能不同，因此它不会实时精确锁定行数。

4. COUNT(*) 的底层执行原理

理解执行原理有助于更好地优化查询。

MyISAM 引擎：
MyISAM 不支持事务，它将表的总行数单独保存在磁盘上。因此执行 COUNT(*) 时直接读取该数值，速度极快。但如果加上 WHERE 条件过滤，它同样需要全表扫描。

InnoDB 引擎：
由于 MVCC 的存在，InnoDB 必须动态计算每一时刻的行数。虽然传统认知是“全表扫描”，但由于 InnoDB 是索引组织表：
1. 主键索引树的叶子节点包含完整数据行。
2. 普通索引（如 idx_salary）的叶子节点只包含主键 ID。
3. **优化策略**：对于单纯的 COUNT(*)，MySQL 优化器会选择最小的那颗索引树（通常是空间占用最小的二级索引）进行遍历。这样减少了从磁盘读取的字节数，提升了 I/O 效率。