mysql COUNT统计集合数量原理_mysql聚合集合讲解

来源：这里教程网时间：2026-02-28 20:37:06 作者：

count(*) 为什么快，但加 WHERE 就变慢？

因为

count(*)

的性能高度依赖存储引擎：MyISAM 引擎把总行数固化在磁盘（

PARTITIONS

表里），不带

WHERE

时直接返回；而 InnoDB 没法这么干——它支持事务和 MVCC，同一时刻不同事务看到的“行数”可能不同，必须逐行判断是否可见。

MyISAM：
SELECT COUNT(*) FROM person;
→ 瞬间返回（哪怕千万行） InnoDB：
SELECT COUNT(*) FROM user;
→ 全表扫描聚簇索引，一行行读、一行行判可见性只要加了
WHERE
条件（哪怕
WHERE 1
），MyISAM 也得全表扫，InnoDB 更是逃不掉

count(1)、count(*)、count(主键) 到底有区别吗？

语义上完全等价：三者都统计「满足条件的非 NULL 行数」。由于

和

永远不为 NULL，

主键

在 InnoDB 中也必然非 NULL，所以最终结果一致。

优化器通常会把
count(*)
和
count(1)
视为同一类操作，甚至内部都转成
count(1)

count(id)
（id 是主键）在有二级索引时，可能走最小的二级索引树（I/O 更少），但实际差异微乎其微别迷信“
count(1)
比
count(*)
快”——MySQL 8.0+ 下二者执行计划几乎一样

count(字段) 和 count(distinct 字段) 是真·慢操作

count(字段)

不仅要判断行是否满足条件，还要读取该字段值并检查是否为

NULL

；

count(distinct 字段)

更狠：需去重，触发临时表或排序，内存/磁盘开销陡增。

SELECT COUNT(email) FROM user;
→ 要读每行的
email
字段，跳过
NULL

SELECT COUNT(DISTINCT email) FROM user;
→ 可能用到
Using temporary; Using filesort
，百万级数据秒变秒级延迟如果业务上确定某列非空（如主键、自增 ID），用
count(*)
更安全，也更易被优化器识别为“可走索引统计”

高频 count 场景怎么避免拖垮查询？

分页总数、后台报表、实时监控——这些地方反复查

COUNT(*)

是大忌。InnoDB 表越大，越容易卡住整个连接池。

用缓存：对变动不频繁的表，把
COUNT(*)
结果存在 Redis，定时或通过 binlog 更新用近似值：对“大概多少条”够用的场景，查
information_schema.PARTITIONS
（InnoDB 表的
TABLE_ROWS
是估算值，误差可能达 40%） 业务妥协：首页只显示“已加载 20 条”，不显示“共 1278923 条”；搜索页用“显示前 5000 条”代替精确总数 千万别用
count(字段)
替代
count(*)
“图省事”——比如写
count(user_name)
以为等于总人数，结果 NULL 用户被漏掉

真正难的不是写对