MySQL 8.0+ 中 COUNT(1) 与 COUNT(*) 执行计划完全一致，优化器在解析阶段即折叠 COUNT(1)，InnoDB 均只遍历主键索引叶子节点确认行存在，不读取任何字段值。
MySQL 8.0+ 的优化器直接把 COUNT(1) 当成 COUNT(*) 处理
这不是“差不多快”，而是执行计划完全一致。你执行 EXPLAIN SELECT COUNT(*) FROM t_user; 和 EXPLAIN SELECT COUNT(1) FROM t_user;，会发现 rows、key、Extra 字段全一样。InnoDB 存储引擎只向 server 层返回“这一行存在”，不传任何列值；COUNT(1) 中的 1 根本不会被读取或计算——它早在解析阶段就被优化器折叠掉了。
COUNT(1) 不跳过字段读取，COUNT(*) 也不读字段
老说法“COUNT(*) 要扫描所有列”是错的。InnoDB 的 COUNT 操作从不访问聚簇索引的 record body，只遍历叶子节点指针（即主键值），确认行存在即可。哪怕表有 200 列、每行 10KB，COUNT(*) 和 COUNT(1) 都只走 B+ 树叶子页链表，不回表、不解码字段。
- 有主键时：两者都扫主键索引
- 有非空二级索引（如
KEY idx_status (status)）时：两者都可能选它——因为更窄，I/O 更少 - 没索引时：两者都触发全表扫描，但实际读的是页目录和记录头，不是整行数据
COUNT(列名) 才真要读字段，且必须判 NULL
这才是性能分水岭。比如 COUNT(nickname)，即使 nickname 有索引，InnoDB 也得从索引项里取出每个 nickname 值，再判断是否为 NULL。如果该列允许 NULL 且无索引，就会强制回表读完整行——比 COUNT(*) 多出数倍 I/O 和 CPU 开销。
-
COUNT(*)和COUNT(1)的耗时差异通常在 ±0.3ms 内，波动主要来自 buffer pool 命中率 - 而
COUNT(email)在 email 允许 NULL 且无索引时，可能比COUNT(*)慢 30%~50% - 别用
COUNT(id)替代COUNT(*)——即使id是主键，语义冗余且无收益
MyISAM 是特例，但你不该依赖它
MyISAM 确实缓存了精确行数，COUNT(*) 可能秒出结果；但 COUNT(1) 是否享受同等待遇，取决于第一列是否 NOT NULL。不过 InnoDB 已是绝对主流，MyISAM 的元数据优化对线上系统毫无参考价值。真正影响 COUNT 性能的，永远是 WHERE 条件有没有走索引、扫描范围有多大，而不是括号里写啥。
最常被忽略的一点：加了 WHERE 后，COUNT(*) 和 COUNT(1) 依然等价，但 COUNT(列名) 的 NULL 判断发生在过滤之后——这意味着它的结果可能和你想的“这张表里该列有多少非空值”完全不是一回事。
