COUNT(*)比COUNT(列名)快的核心在于无需判空，可选最窄索引扫描；而COUNT(列名)必须逐行检查NULL，即使有索引也需回表或解码，且无NOT NULL约束时无法跳过此步骤。
为什么COUNT(*)通常比COUNT(列名)快
核心不在“读不读数据”，而在“要不要判空”。COUNT(*)只确认行存在，优化器可直接扫最小索引（比如单列status索引），每页只取索引项本身；而COUNT(列名)哪怕该列有索引，也必须逐行检查值是否为NULL——这个判断无法跳过，哪怕字段99%非空、哪怕定义了默认值，只要没加NOT NULL约束，就得查。
COUNT(列名)慢的典型场景
常见错误不是写错了，而是没意识到语义已悄然改变：
-
COUNT(email)比COUNT(*)慢几倍，即使email建了唯一索引 → 原因：索引能定位行，但优化器仍需回表或解码取email值判空 -
LEFT JOIN users ON orders.user_id = users.id后写COUNT(users.name)→ 实际统计的是“关联成功且name非NULL”的订单数，既偏移语义又拖慢执行 - WHERE条件带
status = 'active'，但没建INDEX idx_status (status)→COUNT(*)还能走主键索引扫描，COUNT(status)却可能被迫全表扫+逐行解码
索引选法差异直接影响I/O成本
优化器对两者“挑索引”的逻辑完全不同：
-
COUNT(*)会自动选最窄的可用索引（比如KEY idx_flag (is_deleted)比PRIMARY KEY id更优，因叶子节点只存1字节+主键） -
COUNT(列名)只能用该列上的索引，哪怕它比主键还宽（如KEY idx_user_email (user_id, email)），也无法退而求其次选更轻量的索引 - 若该列无索引，
COUNT(列名)必然触发全表扫描+每行解码该列，I/O和CPU开销比COUNT(*)高20%~40%
别被COUNT(1)带偏，盯住两个真实变量
COUNT(*)和COUNT(1)在InnoDB中执行计划完全一致，耗时差异通常在±0.5ms内。真正影响性能的只有：
- 该列是否定义了
NOT NULL？没加就别指望优化器跳过判空 - WHERE条件有没有对应联合索引？
COUNT(*) WHERE status = 'active'没索引照样全表扫 - 你到底要统计“行数”还是“非空值个数”？如果业务真需要后者，先用
COUNT(*) - COUNT(列名)看NULL占比，再决定加索引还是改约束
最容易被忽略的是：NULL判定发生在查询中间结果集上，不是原始表。WHERE和GROUP BY先执行，COUNT(列名)只在过滤/分组后的数据上判空——这个顺序不可逆，偏差也不会报错，只会静默出错。
