MySQL count(*)、count(1)、count(主键id)性能对比与优化实践

先把结论撂这儿：面试里问了一百遍的“count(1)、count(*)、count(主键id)到底谁快”，在绝大多数场景下答案是“差不多”，但如果你只知道这个结论，不知道背后那几层筋和骨头在哪，那下次换个表结构、换个版本，照样掉坑。这篇文章我直接照庖丁解牛的路子来，不背结论，一层层把这三把刀从语义、优化器、索引结构到大表实践全部拆开，顺便把经常被人忽略的count(可空列)和二级索引的坑也一起填了。

适合谁看？准备MySQL面试的人、被线上慢查询count卡过的开发、以及想搞清楚“为什么加了个索引count反而变了”的运维。前两部分讲原理，中间部分是执行计划实测，后面是真正的性能优化和大表方案，看完你基本能把这几个count从里到外讲明白。

1. 先搞清楚“数”的定义：COUNT(expr)与NULL的那笔账

很多人第一步就走错了，以为count是在“数行”。其实它不是。COUNT(expr)的完整语义是：统计表达式expr不为NULL的行数。括号里写的不是“行”，是“表达式”，这个区别就是后面所有坑的总根源。

1.1 三个表达式为什么“看起来一样”

拿一张只有两列的表举例：

sql复制CREATE TABLE t_user (
  id BIGINT PRIMARY KEY,
  nickname VARCHAR(50) NULL
);

然后执行：

sql复制SELECT COUNT(*) FROM t_user;      -- 返回表中总行数
SELECT COUNT(1) FROM t_user;      -- 每行都生成常量1，1永不为NULL，返回总行数
SELECT COUNT(id) FROM t_user;     -- id是主键，主键不可能为NULL，返回总行数

这三条在“结果是总行数”这一点上完全一致，因为：

• * 的语义是“这一行存在”，只要行存在就计数，不看列。
• 1 是常量表达式，对每一行求值结果都是数字1，非NULL，所以等价于计行数。
• id 是主键列，InnoDB规定主键列不允许为NULL，所以判断“id不为NULL”也等价于计行数。

但注意第四条：

sql复制SELECT COUNT(nickname) FROM t_user;  -- 只统计nickname不为NULL的行数

如果表里有100万行，但只有80万人填了昵称，这条语句返回80万。这就是最常见的业务统计口径翻车现场：你以为你在数人，其实你在数“填了资料的人”。有些报表系统里，线上用户总量和活跃用户量差好几倍，查来查去最后定位到一句COUNT(可空字段)，这种问题用EXPLAIN根本看不出来，只能靠语义审计。

1.2 一个反直觉的验证实验

想验证上面说的“表达式求值”机制，可以直接跑一段没有表也能跑的SQL：

sql复制SELECT COUNT(NULL);  -- 结果 0
SELECT COUNT(1);     -- 结果 1

普通select语句里，COUNT(NULL)返回0，COUNT(1)返回1，这就说明count的本质确实是“统计非NULL表达式值的个数”，而不是“数行”。

所以，从语义层面先理出结论：

实际开发里，我见过太多人为了“性能”去写COUNT(非空业务字段)，结果某天DBA把那列的约束从NOT NULL改成NULLABLE后，统计值悄悄变了，排查了半天。所以安全第一的写法永远是COUNT(*)，语义最稳，不会受列约束变化影响。

2. 为什么InnoDB的count总让你觉得“慢半拍”

语义搞清楚之后，下一个问题是：为什么同样是算行数，MyISAM秒出，InnoDB却要全表扫？这不是InnoDB菜，而是它在用“慢”换一个更重要的东西：事务隔离下的数据一致性。

2.1 MyISAM与InnoDB的计数机制差异

MyISAM把“表的总行数”直接存在表的元数据里，执行COUNT(*)时它不需要碰数据文件，直接从元数据读一个数字出来，所以不管表里有多少行，查询时间都是常数级别，也就是常说的时间复杂度O(1)。

InnoDB做不到，原因在于它支持MVCC（多版本并发控制）。同一个表，在事务A开启时的快照里可能是100行，在事务B开启时的快照里可能是101行，因为事务B期间另一个连接插入了一行并且已提交。如果InnoDB也像MyISAM那样在表头存一个总行数，那这个数字到底代表哪个版本？是事务开始时刻的，还是当前时刻的？不管存哪个，都会破坏隔离性。

你还可以这样理解：MyISAM是在黑板上写了一个固定的“总行数”数字，谁来看都一样；InnoDB是每个人拿自己的记账本，按自己的事务快照去数“我这一页里到底该看到多少行”。因为每个人的视角可能不同，所以InnoDB没法维护一个全局万能计数器，只能“现场数”。

2.2 快照读与可见性判断的成本

InnoDB的COUNT(*)走的是快照读，它要去扫一棵索引树，把叶子节点一个个读出来，然后逐行判断“当前事务是否能看到这一行”。这个判断涉及行的trx_id和当前事务的视图（read view）做比较，虽然InnoDB做了很多优化，但本质上这是逐行处理，不是读一个整数。

这也是为什么网上那么多文章说“不要对大表用count，会全表扫描”。严格说InnoDB的count并不是每次都扫聚簇索引，它会挑一棵“小”的索引树来数，但不管挑哪棵，都是遍历，不是读取缓存值。

注意：不要被“全表扫描”这几个字吓到，count场景下它说的不是“扫全量数据行”，而是“扫完整棵索引树的所有叶子节点”。索引树叶子节点存的数据密度比完整行要大得多，所以实际开销没有字面上那么可怕，但也确实没法跟MyISAM的O(1)比。

3. 三种写法执行计划对比：性能差异的真正来源

到了MySQL优化器这一层，事情变得微妙起来。理论上COUNT(1)和COUNT(*)语义等价，但优化器会不会做一些“小动作”？COUNT(主键id)是不是一定更慢？咱们直接用执行计划说话，不猜。

3.1 准备一张带主键和二级索引的测试表

为了对比，我建了一张100万行的订单表，结构如下：

sql复制CREATE TABLE t_order (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL,
  user_id BIGINT NOT NULL,
  amount DECIMAL(10,2) NOT NULL,
  status TINYINT NOT NULL DEFAULT 0,
  created_at DATETIME NOT NULL
) ENGINE=InnoDB;

只建主键索引，然后分别执行三条count语句并看执行计划：

sql复制EXPLAIN SELECT COUNT(*) FROM t_order;
EXPLAIN SELECT COUNT(1) FROM t_order;
EXPLAIN SELECT COUNT(id) FROM t_order;

在只有主键索引的情况下，三条语句的执行计划完全相同：key: PRIMARY，type: index。意思都是扫描主键聚簇索引，读取每一行的主键信息来计数。因为此时整张表只有一棵索引树，优化器没有别的选择。

现实情况是，线上表几乎不会只有主键索引，业务查询会带来各种二级索引。这时候再跑一次：

sql复制ALTER TABLE t_order ADD INDEX idx_status (status);
ALTER TABLE t_order ADD INDEX idx_user_id (user_id);

再次执行EXPLAIN，你会发现三条语句一起变了：

• COUNT(*) 走的是 idx_user_id 或 idx_status（优化器选其中更小的一棵）。
• COUNT(1) 和 COUNT(*) 一样。
• COUNT(id) 仍然走 PRIMARY。

这就很有意思了：为什么COUNT(id)不走二级索引？ 因为二级索引的叶子节点不直接包含主键列作为“数据”，它是以主键值为排序依据挂在B+树上的。虽然扫描二级索引时也会读到主键值，但优化器要“把主键列id作为表达式进行非NULL判断”，逻辑上必须回到聚簇索引去确认id的真实值（尽管InnoDB会做内部优化避免真正的回表），所以优化器直接选择了主键索引，避免逻辑不一致。

3.2 优化器的“折叠”与“等价转换”

MySQL的优化器在解析阶段就会对表达式做常量折叠。COUNT(1)里的1不是列引用，是一个常量表达式，MySQL会直接把COUNT(1)等价转换为COUNT(*)来处理。这在MySQL 5.7和8.0里都能观察到，执行计划一模一样。

有人说COUNT(1)比COUNT(*)快，这一说法在某些老版本里可能源于“从行里取第一列和常量比较”的陈旧印象，现代MySQL里它俩就是同一条执行路径，没有性能差。

我们可以用EXPLAIN ANALYZE实际计时看看（MySQL 8.0.18+）：

sql复制EXPLAIN ANALYZE SELECT COUNT(*) FROM t_order;
EXPLAIN ANALYZE SELECT COUNT(1) FROM t_order;
EXPLAIN ANALYZE SELECT COUNT(id) FROM t_order;

在100万行、无二级索引时，三者执行时间差距在几毫秒以内，基本可以视为同一量级。COUNT(id)因为走聚簇索引，在数据行宽很大时可能略慢，但这个“略慢”跟是否回表无关，纯粹是聚簇索引叶子节点存储的数据更“宽”，遍历时读取的数据页更多。

3.3 小结：谁的“体力活”更重

结合上面的执行计划，可以把三种写法的代价拆成这么几句：

• COUNT(*)：优化器直接按“统计行数”处理，选最小的索引树遍历，性价比最高。
• COUNT(1)：优化器折叠为COUNT(*)，和上面完全一样。
• COUNT(主键id)：在无二级索引时和上面一样；在有二级索引时，优化器倾向走主键聚簇索引，实际扫描的数据量通常比二级索引大。

所以，只要你的表上有二级索引，COUNT(*) / COUNT(1) 大概率比 COUNT(主键id) 快。但是差距有多大？取决于二级索引和聚簇索引的体积差，以及数据行宽。行宽越大、二级索引越窄，差距越明显。

4. 二级索引才是count性能的分水岭

从执行计划的对比能看出来，InnoDB的count本质上是在“挑一棵最小的索引树来数叶子”。所以决定count快慢的，不是括号里写1还是写星号，而是优化器能不能找到一棵足够小的索引树。

4.1 为什么二级索引比主键索引更适合count

InnoDB的聚簇索引叶子节点存储的是整行数据（包括所有列），而二级索引叶子节点只存储索引列+主键值。假设你的表有20个字段，其中有一个created_at日期字段，那么聚簇索引叶子节点要携带20个字段的数据，一个数据页可能只能装几十行；而如果有一个只包含status字段的二级索引，它的叶子节点只携带status和id，数据页里能塞进几百上千行。

count遍历索引树时，需要读入的页数量越少越快。所以优化器优先选叶子节点最“窄”的索引。这叫覆盖索引扫描，它没有回表动作，只是纯粹数叶子节点。

因此，想让count更快，正确的做法不是纠结语句写法，而是：

尽量让表上存在一个“小而精”的二级索引。如果连这样的索引都没有，count就只能去扫聚簇索引，那才是真的慢。

4.2 实测一组对比数据

我在一个类似t_order的表里造了1000万行数据，字段包含id、order_no、user_id、status、amount、created_at。测试结果大致如下（InnoDB buffer pool冷启动后的多次平均，MySQL 8.0.28，8核16G）：

插一句，这个测试环境不是生产环境，具体数字会受内存、磁盘、字段宽度影响，但相对趋势是稳定的：一旦存在窄二级索引，COUNT(*)的速度能有明显提升，而COUNT(id)因为还走聚簇索引，收益有限。

这也是为什么很多规范里直接写“禁止用count(主键id)”——它不一定错，但确实可能错过二级索引的优化机会。

4.3 一个容易踩的坑：COUNT(可空字段)与二级索引的冲突

如果想让count走二级索引，同时又想统计总行数，最稳妥的做法是让二级索引列NOT NULL。

举例：

sql复制SELECT COUNT(status) FROM t_order;

如果status列是TINYINT NOT NULL，那么COUNT(status)与COUNT(*)结果一致，而且优化器也会选中idx_status，性能很好。

但如果你有一天把status改成TINYINT NULL，那么这句COUNT(status)就只统计非NULL的行，结果可能比总行数少，而且优化器仍然走idx_status，结果就悄悄错了。这个问题隐蔽在数据里，不跑对账你根本发现不了。

所以我的建议其实只有一个：业务上要精确的总行数，无脑用COUNT(*)，并且依赖二级索引来做性能优化，不要在count参数里夹带业务字段。

4.4 连表count的坑

如果count出现在JOIN场景，情况更复杂。比如：

sql复制SELECT COUNT(*) FROM t_order o LEFT JOIN t_user u ON o.user_id = u.id;

这个COUNT(*)统计的是“LEFT JOIN后的结果行数”，不是左表行数。如果右表有重复关联，结果会放大。如果你想要左表的行数，应该写COUNT(o.id)，因为右表列在无匹配时为NULL，会导致COUNT(u.id)漏行。

这类问题不是性能问题，是语义问题，但线上踩的人非常多。我的习惯是：JOIN里要统计左表行数，用主表的非空主键；要统计匹配行数，再用COUNT(\*)。

5. 别再死磕count了：大表计数的替代方案

到这里，如果你已经知道“count用星号+二级索引”这回事，说明你掌握了常规优化。但是，无论你优化得多好，count的时间复杂度依然是O(n)，行数涨到亿级别，就算走最窄的二级索引，也要扫上亿条索引记录，几十毫秒到上百毫秒是很正常的。这个量级在一些高并发接口里完全不可接受。

所以更高级的“解牛”是：放弃走count这条路本身。

5.1 从数据字典拿近似值

很多列表页、统计页其实不需要精确计数。比如“搜索到了多少个结果”这种文案，差个几百条用户根本感知不到。这时候可以直接从数据字典拿估算值：

sql复制SELECT table_rows 
FROM information_schema.tables 
WHERE table_schema = 'your_db' AND table_name = 't_order';

这个table_rows来源于InnoDB的采样统计，不是实时精确值，通常有10%左右的偏差，但查询耗时可忽略不计。它非常适合做进度条、报表首页看板这类“大概意思对就行”的场景。

需要注意的是，information_schema.tables里的数据在MySQL 5.7和8.0之间采样逻辑不一样，不能把它当成精确值来用，更别拿它做分页总条数。

5.2 业务侧维护一个“实时计数表”

如果业务真的需要秒级精确总数，那就别依赖count了，自己在业务层维护一张计数表。

最简单方案是建一张统计表：

sql复制CREATE TABLE t_order_count (
  stat_date DATE PRIMARY KEY,
  total_count BIGINT NOT NULL DEFAULT 0
);

每插入一条订单，total_count加1；每删除一条，减1。注意这个加减操作要跟业务操作放在同一个数据库事务里，避免数据不一致。

这个方案有两个问题要提前想清楚：

• 并发更新同一行的热点问题。如果所有业务共享一行统计，写入冲突会很大。可以按日期、按业务域拆行，减少热点。
• 历史数据回放问题。如果做过批量导入、数据订正，计数表也要跟着更新，否则对不上。我的习惯是在数据订正脚本里强制带上计数表的同步操作，并用对账任务定期校正。

5.3 用Redis做计数缓存，但别裸奔

还有一种常见做法是拿Redis存总数。但这里有个很坑的细节：如果先更新数据库，再更新Redis，Redis更新失败会导致缓存和数据库不一致；如果先更新Redis再更新数据库，数据库回滚时Redis已经加了，又多了。

我实践下来比较顺的方案是：

1. 接收业务请求时，直接更新数据库，并把主键ID塞进一个延迟消息队列。
2. 由队列消费者异步去刷新Redis里的计数。
3. Redis的值只作为展示，不参与核心交易判断。
4. 每天凌晨跑一个对账脚本，用COUNT(*)重新校准一次Redis缓存。

这套方案能扛住高并发，也能容忍短暂的计数不一致。如果你的业务连“短时间不一致”都不能忍，那就老老实实回到计数表方案，用事务保证强一致。

5.4 分库分表后怎么count

数据量到了千万甚至亿级，大概率已经分库分表了。这时候SELECT COUNT(*) FROM t_order会直接打到所有分片上再合并结果，性能取决于分片数量和数据总量，通常都不太乐观。

我的做法是：

• 分片键上做精确条件查询时，可以只查某一两个分片，这时COUNT(*)可以用；
• 全局统计时直接走汇总表或离线数仓，不在OLTP链路里做全量count；
• 实时看板类的需求，用前面说的计数表在写入侧累计，查询侧只读计数表。

还有一个很实用的“旁门左道”：如果只是想要一个数量级判断，比如“用户列表是否超过10000条”，可以用LIMIT 1 OFFSET 10000或者SELECT 1 FROM t_order LIMIT 10000, 1去探测，命中就说明超过1万，不用精确count。这种“探测式计数”在一些业务场景里能省不少数据库开销。

最后分享两个实际排查经验

一个是前两年帮客户排查过一次慢SQL，报表页面上一个COUNT(主键id)跑了三秒多。表有一亿多行，主键是BIGINT，行宽特别大，聚簇索引体积接近几十GB。当时把SQL改成COUNT(*)之后，优化器自动选了一个只有几个字节的二级索引，耗时降到六百毫秒。改动只有几个字符，效果立竿见影。

另一个是同事写了个COUNT(remark)统计备注数量，后来某天突然少了20%，查了半天发现是运营在后台清理了一批“remark为NULL”的历史数据。字段改为NOT NULL DEFAULT ''后，数值才恢复。这个案例后来被我写进了团队代码规范：任何“计数类”SQL，除非你明确要数非空值，否则一律用COUNT(*)。

写到这里，几个count的区别和背后的引擎机制就算真正“解完牛”了。最后再给你一个可直接背下来的选择口诀：计数用星号，非空才用列；大表要优化，先看二级索引，再谈缓存和计数表。业务不同，表结构不同，但这一套判断逻辑是通用的。