COUNT(*)比COUNT(列名)快的核心在于无需判空，可直接扫描最小索引；而COUNT(列名)必须逐行取值判断是否为NULL，引发额外I/O和CPU开销。
为什么COUNT(*)通常比COUNT(列名)快得多
核心不是“读不读数据”，而是“要不要判空”。COUNT(*)只确认行存在，优化器可直接扫最小索引（比如单列status索引）的叶子节点，每页只读几个字节；而COUNT(email)哪怕email有唯一索引，也必须逐行取值判断email IS NOT NULL——这常触发回表或解码，I/O 和 CPU 开销翻倍。
COUNT(列名)慢在哪几个关键环节
常见错误现象：COUNT(*) 0.8s 返回，COUNT(department_id) 却要 4.2s，即使该字段建了索引。
- 该列允许
NULL→ 优化器不敢跳过判空，哪怕 99% 行非空也得检查每一行 - 无对应索引 → 强制全表扫描 + 每行解码该列，比
COUNT(*)多出 20%~40% I/O - 有索引但宽 → 比如复合索引
(user_id, created_at)，比主键还宽，遍历成本更高 -
LEFT JOIN后用COUNT(right_table.id)→ 实际统计的是关联成功数，语义已偏移，且需额外 join 判断
什么时候COUNT(列名)可能不慢
只有两个条件同时满足时，COUNT(列名) 才可能接近 COUNT(*) 的性能：
- 该列定义了
NOT NULL约束（不是业务上“应该不为空”，而是 DDL 明确写了） - 该列上有独立、窄、高选择性的索引（比如单列
status索引），且查询无其他复杂条件
即便如此，优化器也不一定等价转换执行计划——实测中仍可能多扫几页索引或触发微小回表。
别被COUNT(1)带偏，盯住真正影响性能的点
COUNT(1) 和 COUNT(*) 在 InnoDB 中执行计划完全一致，耗时差异通常在 ±0.5ms 内，受缓冲池命中率影响远大于写法本身。真正决定快慢的只有两件事：
-
WHERE status = 'active'有没有对应索引？没索引照样全表扫，COUNT(*)也救不了 - 你写的
COUNT(email)，到底是不是真需要“非空数量”？还是只是误当总行数用了？
最容易被忽略的是：NULL 判定发生在查询中间结果集上，不是原始表。一旦加了 WHERE 或 JOIN，COUNT(列名) 统计的已是过滤后、关联后的非空行——这个语义偏差不会报错，只会静默污染指标。
