COUNT(1)和COUNT(*)执行计划完全相同，优化器在逻辑解析阶段就将二者等价折叠，均只判断行存在性而不读字段；真正影响性能的是索引选择与MVCC开销，而非括号内表达式。
MySQL 8.0+ 中 COUNT(1) 和 COUNT(*) 执行计划完全相同
你执行 EXPLAIN SELECT COUNT(1) FROM users 和 EXPLAIN SELECT COUNT(*) FROM users，得到的 type、key、rows、Extra 字段会一模一样。优化器在逻辑解析阶段就将 COUNT(1) 等价折叠为 COUNT(*)，后续走的全是同一套索引扫描路径——比如扫 idx_status 叶子节点，或退化为聚簇索引全扫描。这不是“差不多快”，而是底层指令流、缓冲池访问模式、I/O 轮次全部一致。
COUNT(1) 并不跳过字段读取，也不减少判空开销
一个典型误解是“COUNT(1) 不用读字段，所以省 CPU”。事实是：COUNT(*) 和 COUNT(1) 都不读任何用户字段，只依赖索引页中每条记录的 header 判断“行是否存在”。所谓“判空”只发生在 COUNT(字段) 场景下——此时必须加载该字段值并判断是否为 NULL，可能触发回表或列解码。
-
COUNT(*)：语义为“统计行存在性”，引擎直接计数索引项 -
COUNT(1)：常量表达式永不为NULL，优化器直接映射为同上语义 -
COUNT(status)：必须取status值，遇到NULL就跳过，额外开销真实存在
真正拖慢 COUNT 的从来不是括号里填什么
当你看到 COUNT(*) 耗时飙升，90% 的情况是因为它正在扫描千万行的聚簇索引——而这往往源于：
- 表没有二级索引，优化器被迫扫主键 B+ 树（整行数据都在叶子节点）
-
WHERE条件没走索引，导致无法覆盖扫描，只能全表遍历+可见性判断 - 事务快照大、undo log 链长，MVCC 版本判断本身成了瓶颈
这时候换写法毫无意义：COUNT(1) 同样要扫完全部叶子页；加缓存、用近似值（如查 information_schema.TABLES.TABLE_ROWS）、或改用异步统计才是有效解。
语义混淆比性能差异更危险
线上出过真实事故：把 COUNT(user_id) 当作总用户数上报，结果因部分 user_id 为 NULL 导致漏计 12%。而 COUNT(*) 是 SQL92 标准语法，PostgreSQL、Oracle、SQL Server 全部原生支持且行为一致；COUNT(1) 虽通用，但某些嵌入式数据库对常量表达式支持不稳。括号里填什么，对性能几乎没影响；真正容易被忽略的，是语义漂移——一旦写成 COUNT(字段)，你就已经不是在数“有多少行”，而是在数“该字段有多少非空值”了。
