结论：COUNT(*)与COUNT(1)在InnoDB中性能完全一致，因优化器统一重写为扫描最小索引；真正影响性能的是COUNT(列名)需判空及WHERE条件是否走索引。
直接说结论：在 InnoDB 引擎下，COUNT(*) 和 COUNT(1) 性能完全一致，执行计划一模一样；真正影响速度的，是 COUNT(列名) 的写法和 WHERE 条件是否走索引。
为什么 COUNT(*) 和 COUNT(1) 没差别？
MySQL 8.0+ 的 InnoDB 对这两者做了统一优化：
- 优化器会把 COUNT(*) 和 COUNT(1) 都重写为同一执行路径——扫描最小可用的二级索引（或聚簇索引），只数索引节点数量，不读取任何行数据
- 用 EXPLAIN 查看，两者 type 都是
index，key 指向同一个索引，rows 值完全相同 - COUNT(1) 实际还要多一次常量解析，Server 层需把数字 1 注入执行上下文；COUNT(*) 是语法特例，直通引擎层快速计数逻辑
- 实测百万级表，差异在毫秒级波动范围内，属于测量噪声，不是“差不多”，而是“不可观测差异”
COUNT(列名) 才是性能雷区
它统计的是该列非 NULL 值的数量，不是行数。执行时必须逐行判断值是否为 NULL：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 如果列有二级索引：扫描该索引，读取每个索引项并判空 → 比 COUNT(*) 慢，但尚可接受
- 如果列无索引：只能扫描聚簇索引（全表扫描），读取每行对应字段值再判空 → 性能断崖式下降
- 即使列是主键（如 COUNT(id)）：虽不会为 NULL，但仍需读取主键值，比 COUNT(*) 多一次字段读取开销
- 举例：COUNT(status)（status 允许 NULL）可能比 COUNT(*) 慢 40%~100%，具体取决于 NULL 比例
真正拖慢 COUNT 查询的，从来不是 * 还是 1
关键在 WHERE 条件有没有命中索引：
- COUNT(*) FROM logs WHERE created_at > '2025-01-01' —— 若 created_at 无索引，就是全表扫描
- 此时优化重点是：加索引、改写条件（如分区间统计）、或用近似值（如 SHOW TABLE STATUS 的 Rows 字段，仅作参考）
- 先用 EXPLAIN 看执行计划：type 是
index或range才算健康；若是ALL，问题根本不在 COUNT 写法本身
选型建议：一句话记住
统计总行数，无条件用 COUNT(*)；带条件时优先确保 WHERE 字段有索引；永远别用 COUNT(普通列) 替代 COUNT(*)，除非你明确需要排除 NULL。
