MySQL中COUNT(id)和COUNT(*)哪个效率更高？

前言

在开发中统计行数，很多人习惯使用两种写法：

SELECT COUNT(*) FROM `user_login_log` WHERE `date` = CURDATE();SELECT COUNT(id) FROM `user_login_log` WHERE `date` = CURDATE();

网上曾流传一种说法：COUNT(*) 需要扫描整行数据，而 COUNT(id) 只读取主键，因此 COUNT(id) 更快。

这个观点在当前的 InnoDB 引擎下，完全不成立。

本文基于 InnoDB 底层原理，详细解释 COUNT(*)、COUNT(id)、COUNT(普通字段) 的差异，并给出生产环境的标准编码规范。

先说明环境：全文基于 MySQL InnoDB（5.7 / 8.0，线上最常用版本）；MyISAM 机制不同，文末单独提及。

一、先搞懂三个COUNT语法的语义

1. COUNT(*)

根据 SQL 标准定义：统计满足查询条件的所有行数，不进行任何 NULL 判断。

MySQL 官方对 COUNT(*) 做了专门优化，优化器会优先选择当前表体积最小的二级索引进行扫描计数，无需读取聚簇索引的完整行数据。

2. COUNT(id)

语义：统计 id IS NOT NULL 的记录行数。

通常 id 是主键，主键强制非空，因此逻辑上等价于统计总行数。

执行逻辑：扫描索引，取出主键 id 值，判断不为 NULL 后再计数。

3. COUNT(普通业务字段)

COUNT(login_ip)

语义：统计 login_ip IS NOT NULL 的记录。

这里存在两个风险：

1. 如果字段允许 NULL，统计结果与实际行数不一致，易引发业务 BUG；
2. InnoDB 需要取出字段真实值来判断 NULL，开销比 COUNT(*) 大很多。

二、核心结论（InnoDB）

带 WHERE 条件统计时，COUNT(*) 和 COUNT(id) 的性能几乎没有差异。

无需纠结选哪个，两者的执行计划、扫描行数、IO 开销基本持平。

底层原因很简单：InnoDB 二级索引的叶子节点本身就存放着主键 id。无论优化器选择哪个二级索引进行扫描计数：

• COUNT(*)：只需计数索引条目，不需要读取字段值
• COUNT(id)：除了计数，还要额外取出 id 值做非空判断

理论上 COUNT(*) 会略微优于 COUNT(id)，但在绝大多数场景下，这种差异几乎无法感知。

三、误区拆解：为什么会流传 COUNT(id) 更快？

这个谣言的来源，主要来自老旧 MyISAM 的认知混淆，加上早期网络文章以讹传讹：

1. MyISAM 在不带 WHERE 条件时，COUNT(*) 确实很快，因为引擎缓存了总行数；但 MyISAM 现在已不是主流；
2. 很多人主观认为 * 代表读取整行数据，实际上 MySQL 优化器根本不会去读完整行；
3. 没有区分“有无 WHERE 条件”，笼统下结论。

重点纠正：InnoDB 中，COUNT(*) 不会读取完整一行数据，优化器只利用索引条目数量来统计。

四、无WHERE条件的特殊场景

-- 查询整张表总条数SELECT COUNT(*) FROM `user`;SELECT COUNT(id) FROM `user`;

很多人发现这条 SQL 查询很慢。

原因在于：InnoDB 的事务多版本机制，无法缓存表总行数，无论 COUNT(*) 还是 COUNT(id)，都必须扫描索引来统计，两者速度依旧基本一致。

若需高频查询表总量，可考虑使用 Redis 缓存或定时统计表总数，避免频繁 COUNT 扫描索引。

五、新增对比：COUNT(常量)

额外拓展一种写法：

SELECT COUNT(1) FROM `user_login_log` WHERE `date` = CURDATE();

在新版本 MySQL 中，COUNT(1) 会被优化器等价优化为 COUNT(*)，性能同样持平。因此无需盲目推崇 COUNT(1)。

六、一张表清晰区分三种写法

写法	作用	是否判NULL	性能建议	风险
COUNT(*)	统计所有符合条件行	不判断NULL	推荐，官方标准	无
COUNT(id)	统计id不为NULL的行	判断NULL	可用，略逊于COUNT(*)	id必须为主键非空，否则结果异常
COUNT(login_ip)	统计login_ip不为NULL的行	判断NULL	不推荐	字段存在NULL时统计数量失真，开销更大

七、线上编码规范建议

优先使用 COUNT(*)，遵循 SQL 标准，语义清晰，MySQL 官方推荐；

-- 标准写法SELECT COUNT(*) AS active_num FROM user_login_log WHERE `date` = CURDATE();

禁止使用 COUNT(普通业务字段) 统计表总行数；

如果确实需要统计“某字段不为空”的数据，才用 COUNT(字段名)；

-- 合理场景：统计有登录IP的用户SELECT COUNT(login_ip) FROM user_login_log WHERE `date` = CURDATE();

不要为了“优化性能”把 COUNT(*) 强行改成 COUNT(id)，这属于无效优化；

大表频繁全量 COUNT 统计，建议使用缓存预聚合方案。

八、实战验证方式

使用 EXPLAIN 对比两条 SQL 的执行计划即可直观感受：

EXPLAIN SELECT COUNT(*) FROM user_login_log WHERE `date` = CURDATE();EXPLAIN SELECT COUNT(id) FROM user_login_log WHERE `date` = CURDATE();

观察输出中的 type、key、rows，基本完全一致，可直观证明性能差距极小。

九、补充：MyISAM简要区分（了解即可）

MyISAM 引擎内部保存了表总行数：

SELECT COUNT(*) FROM `user`; -- 不加WHERE，瞬间返回

但只要带上 WHERE 条件，MyISAM 同样需要扫描数据，此时 COUNT(*) 与 COUNT(id) 差距也不大。

新项目基本不会使用 MyISAM，此处仅作知识拓展。

十、全文总结

1. InnoDB 引擎下，COUNT(*) 与 COUNT(id) 性能几乎持平，COUNT(*) 理论小幅领先；
2. 网传“COUNT(id) 速度更快”属于过时谣言，不要作为优化依据；
3. 统计满足条件全部行数，统一使用 COUNT(*)；
4. 杜绝用 COUNT(普通字段) 统计总行数，存在逻辑 BUG 与性能损耗；
5. SQL 优化应将重心放在索引设计，不要在 COUNT 写法上做无效内卷。

写代码记住一条准则：先保证语义准确，再追求性能。符合 SQL 标准的 COUNT(*) 是兼顾可读性与性能的最优选择。