MySQL 8.0+中COUNT()与COUNT(1)执行计划完全相同，优化器将其等价重写为扫描最小索引，不读行数据；COUNT()语义标准、Server层处理更轻量，性能略优但差异可忽略。
MySQL 8.0+ 中 COUNT(1) 和 COUNT(*) 执行计划完全一样
你执行 EXPLAIN SELECT COUNT(*) FROM orders 和 EXPLAIN SELECT COUNT(1) FROM orders，会发现 type 都是 index，key 指向同一个索引，rows 值也完全一致。这是因为 InnoDB 优化器在解析阶段就将两者等价重写为“扫描最小可用索引（通常是主键或最小二级索引）”，不读取任何行数据，只统计索引节点数量。
常见错误现象：看到某次 COUNT(1) 耗时 12ms、COUNT(*) 耗时 14ms，就认为前者更快 → 实际是缓冲池命中率、页预读状态或并发查询干扰导致的毫秒级抖动，不是函数本身差异。
COUNT(1) 在 Server 层多一次常量注入，理论开销略高
COUNT(*) 是 SQL 标准语法特例，MySQL Server 层识别后直接交由引擎层走快速计数路径；而 COUNT(1) 需要把常量 1 注入执行上下文，多一次表达式解析和值绑定操作。虽然这个开销在纳秒级，但严格来说，COUNT(*) 更“轻量”。
- 在极低负载、空缓存、百万级小表上做千次压测，
COUNT(*)的 P95 耗时通常稳定低 0.1–0.3ms - 这个差距远小于网络往返、连接建立、结果集序列化等环节的波动，线上无法感知
- 旧资料说“
COUNT(1)不解析列所以更快”，是针对 Oracle 8i 或 MySQL 4.x 的过时结论，现代优化器早就不这么工作了
COUNT(列名) 才是真正影响性能的变量，别被写法带偏
拖慢 COUNT 查询的从来不是 * 还是 1，而是是否要读真实数据：
-
COUNT(id)（id是主键）：仍需读取主键值并确认非 NULL，比COUNT(*)多一次值提取，略慢 -
COUNT(status)（status允许 NULL 且无索引）：强制全表扫描 + 每行判空，可能慢 2–5 倍 -
COUNT(status)有索引但列允许 NULL：优化器可能用索引，但仍要过滤掉索引中不存的 NULL 条目，不如COUNT(*)直接扫聚簇索引干脆 - 真正该盯的是
WHERE条件 —— 如果COUNT(*) FROM logs WHERE created_at > '2025-01-01'没走索引，再换COUNT(1)也没用
跨数据库兼容性和语义清晰度才是关键取舍点
COUNT(*) 是 SQL92 标准唯一定义“统计行数”的写法，PostgreSQL、SQL Server、Oracle、SQLite 全部行为一致；COUNT(1) 虽然也能跑，但属于实现细节层面的等价替代，容易引发误解（比如新人以为它在“检查某列是否等于 1”）。
阿里《Java 开发手册》【强制】要求用 COUNT(*)，不是因为性能，而是避免团队内歧义和未来迁移风险。MyISAM 表虽能靠元数据缓存让两者都 O(1)，但 InnoDB 才是线上主流，而它的行为已彻底统一。
真正容易被忽略的点是：当表没有二级索引时，COUNT(*) 和 COUNT(1) 都退化为聚簇索引扫描 —— 此时索引大小、缓冲池利用率、MVCC 版本链长度，才决定实际耗时，跟写法无关。
