为什么SQL中COUNT(1)比COUNT(*)在某些情况下执行速度更快？

本文共计947个文字，预计阅读时间需要4分钟。

大多数主流数据库（如MySQL 8.0、PostgreSQL、SQL Server、Oracle）的查询优化器会将 `COUNT(1)` 和 `COUNT(*)` 视为等价操作，最终生成完全相同的执行计划。这并非诡计，而是SQL标准语义和优化器长期演化的结果：

所以如果你看到某篇老文章说“COUNT(1) 比 COUNT(*) 快”，大概率是基于以下情况之一：

• 使用了非常早期的 MySQL 版本（如 5.5 或更早），且未开启优化器增强
• 测试时恰好命中了缓存或统计信息偏差，误判了耗时
• 对比的是 COUNT(col) 而非 COUNT(*)，混淆了 NULL 判断开销

真正影响 COUNT 性能的关键是列是否可空

COUNT(column) 的性能差异不来自“写法”，而来自语义：它必须逐行检查该列是否为 NULL。哪怕这个列上有索引，只要不是 NOT NULL 约束，优化器就无法跳过 NULL 判断。

常见陷阱包括：

• COUNT(department_id) —— 如果该字段允许 NULL，即使有索引，也可能触发回表或全索引扫描
• COUNT(*) WHERE status = 'active' —— 条件过滤后，优化器可能选择走二级索引 + 聚簇索引查找，比直接扫主键还慢
• 在无主键的堆表（如 MySQL MyISAM 或某些归档表）上，COUNT(*) 可能退化为全表扫描，此时 COUNT(1) 并不能改善

什么时候 count(1) 真的比 count(*) 快？极少数例外场景

这类情况现在极少出现，但需知道边界：

• MySQL 使用 MyISAM 引擎且表无主键：MyISAM 维护了行数元数据，COUNT(*) 可直接返回；但若写了 COUNT(1)，旧版本优化器可能误判为需要扫描——注意，这是 bug 级行为，不是设计优势
• 某些嵌入式或轻量级数据库（如 SQLite 3.20 之前）未对 COUNT(*) 做特殊优化，而把 COUNT(1) 当作常量表达式提前折叠
• ORM 自动生成语句时强制拼 COUNT(1)，恰好绕过了某个 ORM 对 COUNT(*) 的解析 Bug（例如早期 Hibernate 对 HQL 的处理）

这些都不是你应该主动依赖的优化点，而是兼容性补丁或历史包袱。

想让 COUNT 快，别纠结 1 还是 *，盯紧三件事

实际调优中，95% 的慢 COUNT 问题跟写法无关，而和这三点强相关：

• 确保被统计的表有明确主键（最好是自增整型），让优化器能用最小索引（如主键 B+ 树的叶子节点数）估算或精确计数
• 避免在大表上执行无条件 COUNT(*) —— 改用近似值（如 PostgreSQL 的 pg_class.reltuples，MySQL 的 INFORMATION_SCHEMA.TABLES）或加缓存层
• 如果必须精确统计带条件的行数，优先给 WHERE 字段建联合索引，并确认该索引能覆盖 COUNT 所需的所有列（避免回表）

最常被忽略的一点：很多 DBA 以为加个索引就能加速 COUNT(col)，但如果 col 允许 NULL，索引里就不存这些记录，结果直接不准——COUNT(col) 不是“数索引行数”，而是“数非 NULL 行数”，这两者在索引结构里根本不是一回事。