一、实测环境与数据准备

为了彻底厘清三种COUNT用法的性能差异，我们在相同硬件环境（4核8G内存，SSD硬盘）下搭建了测试环境：

• MySQL 8.0.28（InnoDB引擎）：创建测试表user_test，包含主键id、普通索引列username、非索引列age，插入1000万条随机数据，平均每行大小约512字节。
• PostgreSQL 14.5：创建结构相同的表user_test，使用generate_series生成1000万条测试数据，开启autovacuum自动清理。

二、MySQL（InnoDB）实测：谁是性能王者？

2.1 基础性能对比

在无WHERE条件的全表计数场景下，我们执行了5轮测试，取平均值：

关键发现：COUNT(*)与COUNT(1)性能几乎一致，耗时仅差0.01秒，这源于InnoDB优化器会选择最小的二级索引（本例中idx_username索引大小52MB，远小于主键索引的390MB）进行扫描。而COUNT(age)因无索引，触发全表扫描，耗时是前两者的2.5倍。

2.2 执行计划深度解析

通过EXPLAIN分析COUNT(*)和COUNT(1)的执行计划，发现两者完全一致：

EXPLAIN SELECT COUNT(*) FROM user_test;
+----+-------------+----------+------------+-------+---------------+-------------+---------+------+----------+----------+-------------+
| id | select_type | table    | partitions | type  | possible_keys | key         | key_len | ref  | rows     | filtered | Extra       |
+----+-------------+----------+------------+-------+---------------+-------------+---------+------+----------+----------+-------------+
|  1 | SIMPLE      | user_test| NULL       | index | NULL          | idx_username| 202     | NULL | 9980612  |   100.00 | Using index |
+----+-------------+----------+------------+-------+---------------+-------------+---------+------+----------+----------+-------------+

Using index表明优化器使用了覆盖索引扫描，无需回表读取数据行，直接通过索引计数。这解释了为何COUNT(*)比COUNT(id)更快——二级索引叶子节点仅存储索引列和主键，体积远小于聚簇索引（存储整行数据）。

2.3 InnoDB存储引擎的底层优化

InnoDB行记录结构（如COMPACT格式）中，变长字段长度列表和NULL值列表仅占用少量额外空间，而二级索引的B+树结构使得遍历成本极低。下图展示了InnoDB行记录的存储布局，揭示了COUNT(*)能高效利用二级索引的原因：

原理点睛：InnoDB不会像MyISAM那样存储总行数，因为MVCC机制下不同事务可见的行数不同。但优化器会自动选择最小的索引树（通常是二级索引）进行扫描，这就是COUNT(*)和COUNT(1)性能优异的核心原因。

三、PostgreSQL实测：MVCC下的计数困境

3.1 基础性能对比

在相同数据量下，PostgreSQL的测试结果呈现不同特征：

关键发现：PostgreSQL首次执行COUNT(*)耗时是MySQL的12倍，这源于其MVCC实现——每行记录需通过xmin和xmax判断事务可见性。但缓存后（数据页载入内存），性能显著提升，此时Index Only Scan通过可见性映射（Visibility Map）跳过已清理页面，效率接近MySQL。

3.2 可见性映射与索引优化

PostgreSQL的可见性映射（VM） 记录数据页是否所有元组对当前事务可见。当表开启autovacuum（默认开启），VM会定期更新，使得COUNT(*)可通过索引扫描直接计数，无需访问表数据。我们通过调整autovacuum参数优化性能：

ALTER TABLE user_test SET (autovacuum_vacuum_scale_factor = 0, autovacuum_analyze_threshold = 1000);

优化后，56万数据量的COUNT(*)执行时间从6秒降至1秒内，VM的作用至关重要。

四、存储引擎原理深度对比

4.1 MySQL InnoDB vs PostgreSQL核心差异

4.2 为何COUNT(列名)性能总是垫底？

无论是MySQL还是PostgreSQL，COUNT(列名)都需要：

1. 读取列值（即使是索引列，也需确认非NULL）；
2. 若列允许NULL，需额外判断NULL值（索引不存储NULL，故需回表或扫描全表）；
3. 无法利用“最小索引”优化，只能使用该列对应的索引（可能较大）。

例如，在MySQL中，COUNT(age)因age无索引，触发全表扫描，需读取每行age值并判断是否为NULL，耗时1.23秒，远超COUNT(*)的0.48秒。

五、不同场景最佳实践

5.1 数据量与索引选择

• 小表（<10万行）：三种用法性能差异可忽略，推荐使用COUNT(*)（语义最清晰）；
• 大表（>1000万行）： MySQL：优先COUNT(*)或COUNT(1)，确保表有二级索引； PostgreSQL：创建小字段索引（如INT类型），并定期VACUUM更新VM。

5.2 高并发计数优化方案

• 近似计数：使用SHOW TABLE STATUS（MySQL）或pg_class.reltuples（PostgreSQL）获取估算值，误差率约1%，但耗时<1ms；
• 缓存计数：通过Redis的INCR/DECR维护计数器，适合写少读多场景；
• 汇总表：创建独立计数器表，通过触发器或应用层事务更新，确保数据一致性。

5.3 实战决策树

根据业务场景选择COUNT方法，可参考以下决策路径：

1. 是否需要精确计数？ 否 → 用近似计数（如pg_class.reltuples）； 是 → 进入下一步。
2. 表是否有索引？ 无索引 → 用COUNT(*)（MySQL会扫聚簇索引，PostgreSQL扫表）； 有索引 → 若需统计非NULL列，用COUNT(列名)，否则用COUNT(*)。

六、实测结论与行业误区澄清

6.1 三大常见误区

1. “COUNT(1)比COUNT(*)快”：实测证明两者性能完全一致，优化器会将COUNT(1)解析为COUNT(*)；
2. “COUNT(*)会扫描全表”：MySQL InnoDB会选择最小二级索引，PostgreSQL在VM更新后也会走Index Only Scan；
3. “PostgreSQL COUNT性能永远不如MySQL”：通过索引优化和VM维护，PostgreSQL在缓存命中时性能接近MySQL。

6.2 终极选择建议

• MySQL用户：无脑用COUNT(*)，优化器会自动选择最优索引；
• PostgreSQL用户：优先COUNT(*)，并确保表开启autovacuum，创建小字段索引；
• 通用原则：避免COUNT(列名)除非需统计非NULL值，此时务必为列创建索引。