MySQL 8.0+ 中 COUNT(*) 比 COUNT(1) 更优，因前者有语义级专用优化路径，直接读取索引元信息，后者需额外解析常量表达式；二者执行计划完全一致，性能差异可忽略，语义清晰与跨库兼容性才是关键。
MySQL 8.0+ 中 COUNT(*) 是专用优化路径，COUNT(1) 反而多一层解析
MySQL Server 层对 COUNT(*) 有语义级特殊识别：只要没 WHERE 条件、没显式锁（如 SELECT COUNT(*) FROM t FOR UPDATE），InnoDB 就直接从聚簇索引的元信息或叶子节点数中取值，不触发逐行遍历。而 COUNT(1) 虽然最终也走同样引擎路径，但 Server 层仍需做一次“表达式求值”解析——哪怕只是确认常量 1 非空，也存在微小的语法树构建与校验开销。实测中这个差异在纳秒到微秒级，但逻辑上它确实不是“零成本”。
COUNT(1) 和 COUNT(*) 执行计划完全一致，别被老资料误导
在 MySQL 5.7+ 版本里，执行 EXPLAIN SELECT COUNT(*) FROM t; 和 EXPLAIN SELECT COUNT(1) FROM t;，你会看到：type 都是 index，key 都指向最小可用索引（比如 PRIMARY 或 idx_dummy），Extra 都是 Using index。这说明优化器已将二者等价重写。所谓“COUNT(1) 更快”，基本只可能出现在以下情况：
- 测试时缓存未清，某次
COUNT(1)恰好命中了预热后的索引页 - 对比的是极老版本（如 MySQL 4.1）或非标准引擎（如某些嵌入式 SQLite）
- 把
COUNT(id)的慢误当成COUNT(*)的慢，再拿COUNT(1)做对比
COUNT(列名) 才是真性能分水岭，和括号里写啥无关
真正拉开性能差距的，从来不是 * 还是 1，而是你有没有碰字段值：
-
COUNT(*)和COUNT(1)：都不读字段，只遍历索引叶节点 -
COUNT(id)：即使id是主键，引擎也得把每个id值从页中定位、解包、传给 Server 层——多了内存拷贝和类型处理 -
COUNT(email)：若该字段允许NULL，还得额外判断每行是否为NULL；若没索引，直接退化成全表扫描
所以当你发现 COUNT(1) “比 COUNT(*) 快一点”，大概率是 COUNT(*) 被某个隐式条件（比如查询上下文里的临时表、视图重写）拖慢了，而不是 COUNT(1) 自身更快。
跨数据库兼容性和语义清晰度才是关键取舍点
PostgreSQL、SQL Server、Oracle 都明确推荐用 COUNT(*)，不仅因它最快，更因它的语义无歧义：“我要整行数”。而 COUNT(1) 在部分旧版 SQL Server 中会触发警告，在 TiDB 某些版本里甚至被当作非标准写法拒绝。团队里新人看到 COUNT(1)，容易误以为它和主键或自增有关；看到 COUNT(*)，一眼就懂。
真正该花时间调优的，是索引设计（比如加个 TINYINT 的假索引加速统计）、是否接受近似值（查 INNODB_SYS_TABLESTATS），或者业务层异步维护计数表——而不是在 * 和 1 之间反复横跳。
