mysql优化器会把count(1)重写成count(*)，二者在mysql 8.0+中语义、执行计划、扫描路径和性能完全一致；真正影响count性能的是索引可用性、where条件及是否触发全表扫描，而非括号内写法。
MySQL优化器会把COUNT(1)重写成COUNT(*)
MySQL 8.0+ 的查询优化器对 COUNT(1) 做了显式等价折叠：只要没有 WHERE 或其他复杂子句干扰，它会在逻辑优化阶段直接将 COUNT(1) 替换为 COUNT(*)，后续生成的执行计划、扫描索引路径、I/O 行为完全一致。
你用 EXPLAIN FORMAT=TREE 或 EXPLAIN ANALYZE 查看，两者输出的执行树和实际耗时几乎无法区分（实测差值常在 ±0.3ms 内，远小于缓冲池抖动带来的波动）。
COUNT(1)并不会跳过字段读取
一个常见误解是“COUNT(1) 不读字段所以更快”。实际上，在 InnoDB 中：
-
COUNT(*)和COUNT(1)都不读任何用户字段，只遍历索引页（B+ 树叶子节点） - 即使走二级索引，也只取索引项本身（比如
KEY idx_status (status)），不回表、不解析行记录 - 所谓“读字段”只发生在
COUNT(字段)且该字段允许 NULL 时——必须取值判空
真正影响性能的是索引，不是括号里填什么
决定 COUNT 快慢的核心，从来不是写 * 还是 1，而是：
- 有没有可用的二级索引：优化器会自动选最小的索引（比如单列
status索引比联合索引小，就优先扫它） - 有没有 WHERE 条件：带
WHERE status = 'active'时，COUNT(*)能直接走idx_status覆盖扫描，毫秒级返回 - 是否强制全表扫描：无索引 + 无 WHERE → 只能扫聚簇索引（主键 B+ 树所有叶子节点），行数越多越慢
这时候换写法毫无意义——COUNT(1) 同样要扫完全部叶子页。
别被 MyISAM 的历史行为带偏
MyISAM 表元数据里存了精确行数，所以 COUNT(*) 无条件 O(1) 返回；但 COUNT(1) 在某些旧版本中未必享受同等优化。这导致早年有“COUNT(1) 更快”的说法。
而你现在用的几乎肯定是 InnoDB（MySQL 5.7+ 默认引擎），这个前提已不成立。强行沿用旧经验，反而可能掩盖真实瓶颈——比如忘了给 WHERE 条件建索引。
最易被忽略的一点：当 COUNT(*) 出现明显延迟时，90% 的情况不是写法问题，而是没意识到它正在扫上千万行的主键索引——此时加缓存或改用近似统计（如查 information_schema.TABLES.TABLE_ROWS）比纠结括号内容实在得多。
