COUNT()与COUNT(1)语义和性能完全等价，均统计所有满足条件的行（含NULL），执行路径一致、无性能差异；推荐优先使用COUNT()因其符合SQL标准、跨数据库兼容性好、语义更清晰。
COUNT(*) 和 COUNT(1) 在绝大多数实际场景中返回完全相同的结果，执行逻辑高度一致，没有本质区别。 它们都统计满足条件的行数（含 NULL 值），不依赖具体列内容，也不过滤空值。
语义与行为完全等价
两者都表示“统计结果集中的所有行”，MySQL 优化器对它们的处理方式完全相同：
- COUNT(*) 是 SQL 标准语法，明确表达“统计所有行”的意图，语义最清晰；
- COUNT(1) 中的 “1” 是常量表达式，MySQL 将其视为非 NULL 的虚拟列，因此每行都贡献 1 次计数；
- 无论表中是否存在 NULL 值、是否有索引、字段类型如何，只要行被 WHERE 条件选中，就会计入；
- 例如：对含 50 万 NULL 性别值的 users 表执行
COUNT(*)或COUNT(1)，结果都是总行数（如 100 万）。
执行过程高度一致，性能基本无差异
在 InnoDB 引擎下，二者均走相同的优化路径：
- 优先选择最小的二级索引（key_len 最小）进行遍历，避免访问聚簇索引（主键索引）以减少 I/O；
- 若无二级索引，则退化为扫描主键索引；
- 不读取行数据（不回表），仅按索引页逐页计数，时间复杂度均为 O(N)；
- 官方文档及实测（MySQL 5.7+）证实：执行计划、耗时、资源消耗几乎完全一致。
为什么建议优先用 COUNT(*)
这不是性能选择，而是规范性与可维护性考量：
- COUNT(*) 是 ANSI SQL 标准写法，所有主流数据库（PostgreSQL、Oracle、SQL Server）均原生支持且语义统一；
- COUNT(1) 属于 MySQL 兼容性写法，在部分数据库（如早期 SQL Server）中可能引发解析歧义或警告；
- 团队协作中，COUNT(*) 更易被新人理解，降低误读风险（比如误以为 COUNT(1) 与主键有关）；
- 现代 MySQL 版本已对 COUNT(*) 做深度优化，无需人为“替换”为 COUNT(1) 来“提速”。
COUNT(*) 与 COUNT(列名) 的关键分界点
真正影响结果和性能的是 COUNT(列名)，它和前两者有本质不同：
- COUNT(列名) 只统计该列值 非 NULL 的行，结果可能小于 COUNT(*)；
- 若该列有索引，COUNT(列名) 可能走索引快速统计（尤其非空率高时）；
- 若该列无索引且 NULL 值多，COUNT(列名) 实际要检查每行该列是否为 NULL，开销反而可能略高于 COUNT(*)；
- 举例：
COUNT(gender)在 50 万 NULL 性别数据中返回 50 万，而COUNT(*)返回 100 万。
