count() 和 count(1) 执行计划完全相同，现代数据库在解析阶段即等价转换，性能无差异；count(列名) 才是真正性能陷阱，需判空且可能全表扫描；应统一使用标准 count()。
COUNT(*) 和 COUNT(1) 的执行计划完全一样
你用 EXPLAIN 看两者生成的执行计划，节点类型、扫描方式、I/O 次数、CPU 开销全部一致。现代数据库（MySQL InnoDB、PostgreSQL、SQL Server、Oracle 12c+）在解析阶段就识别出 COUNT(1) 中的 1 是非空常量，直接等价转换为 COUNT(*) 语义，不会多读一列、不判空、不额外计算。
常见错误现象：
- 看到老文章说“
COUNT(1)不用解析*，所以更快” → 这是 Oracle 8i 时代的认知，优化器早就不这么干了 - 监控里偶然发现
COUNT(1)耗时低几毫秒 → 实际是缓冲池命中、网络抖动或并发干扰，不是函数本身差异
COUNT(*) 是 SQL92 标准写法，语义明确且兼容性最强
COUNT(*) 明确定义为“统计物理行存在性”，和 NULL、列定义、存储引擎无关；而 COUNT(1) 属于实现细节层面的等价替代，容易引发误解（比如新人以为它在检查某列是否等于 1）。
阿里巴巴《Java 开发手册》【强制】要求：不要用 COUNT(1) 或 COUNT(列名) 替代 COUNT(*)。
使用场景注意点：
- MyISAM 表无 WHERE 条件时，
COUNT(*)直接返回元数据缓存值；COUNT(1)仅当第一列为NOT NULL才能享受该优化 - InnoDB 表两者都走最小索引（通常是主键），速度取决于索引大小和缓冲池状态，跟写法无关
COUNT(列名) 才是真正的性能陷阱
COUNT(列名) 统计的是该列非 NULL 值数量，行为完全不同于前两者：
- 如果列允许 NULL 且无索引 → 触发全表扫描 + 每行判空，明显更慢
- 即使加了索引，数据库仍需遍历索引确认覆盖性（索引不存 NULL，但需验证是否所有非 NULL 值都被索引覆盖）
- 只有当列定义为
NOT NULL且优化器识别到该约束，才可能跳过判空，但仍不一定比COUNT(*)快
真正影响性能的从来不是写 COUNT(*) 还是 COUNT(1)，而是表结构、索引设计、WHERE 条件是否存在，以及是否在事务活跃期对大表做无条件统计。
别被“常量更快”的直觉带偏
有人觉得 COUNT(1) 比 COUNT(*) “更具体”，所以更快 —— 这种直觉在 SQL 里不成立。数据库优化器不按字面意思执行，而是按语义重写。你写 COUNT(1)、COUNT('hello')、甚至 COUNT(42)，结果都一样，计划也一样。
最容易被忽略的一点：如果你在代码里混用 COUNT(*) 和 COUNT(1)，后续排查慢查询或审计规范时，会多一层无意义的判断成本。统一用 COUNT(*)，省心、标准、无歧义。
