结论：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。