COUNT(*)通常比COUNT(列名)快，因其仅需判断行存在性、走存在性扫描路径；而COUNT(列名)必须逐行读取并判空该列值，即使有索引也常触发解码或回表，性能显著下降。
COUNT(*) 通常比 COUNT(列名) 快，核心原因不是“不读数据”，而是“不用判空”。现代数据库（MySQL 8.0+、PostgreSQL、SQL Server）对 COUNT(*) 和 COUNT(1) 都走存在性扫描路径，只遍历索引叶子节点计数；而 COUNT(列名) 即使该列有索引，也必须确认每行该列值是否为 NULL，这会触发额外判断、解码甚至回表。
为什么 COUNT(*) 能跳过列值读取
优化器知道 COUNT(*) 只关心“行是否存在”，所以会选最小可用索引（比如 KEY idx_status (status)）扫一遍叶子节点，每页只读索引项本身，I/O 极少。InnoDB 主键 B+ 树的叶子节点存的是整行，但二级索引叶子节点只存索引列 + 主键值——COUNT(*) 就是靠这个“更窄的索引”省下大量磁盘读。
常见错误现象：COUNT(*) 执行快，COUNT(email) 却慢几倍，即使 email 字段建了唯一索引。原因在于：该索引虽能定位行，但优化器仍需从聚簇索引中取出 email 值判空，无法绕过。
- 如果表只有主键，
COUNT(*)默认扫主键索引 - 如果有多个二级索引，
COUNT(*)会自动选最短的那个（比如单列status索引比复合索引(user_id, created_at)更优） -
COUNT(列名)只能使用该列上的索引，哪怕它比主键索引还宽，也没得选
COUNT(列名) 的 NULL 判定开销远超直觉
COUNT(列名) 不是“顺便看看这一列”，而是强制逐行执行 列名 IS NOT NULL 判断。哪怕该列 99% 非空，只要定义允许 NULL，优化器就无法跳过检查——因为 INSERT 时没显式赋值、应用层漏传、DEFAULT 表达式返回 NULL，都可能让某一行悄悄变成 NULL。
性能影响具体体现在：
- 无索引时：必须全表扫描 + 每行解码该列，比
COUNT(*)多出 20%~40% I/O 和 CPU - 有索引但列 NULL 占比高（如 60%）：二级索引页更多、遍历成本更高，且部分数据库仍需回表确认真实值
- 在
LEFT JOIN后用COUNT(right_table.id)：实际统计的是关联成功数，语义已偏移，还拖慢执行
别被 COUNT(1) 分散注意力，盯住两个真问题
COUNT(1) 和 COUNT(*) 在 InnoDB 中执行计划完全一致，耗时差异通常在 ±0.5ms 内，受缓冲池命中率影响远大于写法本身。真正决定性能的只有两点：
-
该列是否定义了 NOT NULL？如果没加约束，优化器不敢跳过判空，再快的索引也白搭 -
WHERE 条件有没有对应联合索引？COUNT(*) WHERE status = 'active'必须有INDEX idx_status (status)才能走索引扫描；否则照样全表扫
最容易被忽略的一点：NULL 处理是 SQL 标准强制行为，发生在 WHERE 和 JOIN 之后——COUNT(列名) 统计的是当前结果集里的非空数，不是原始表分布。复杂查询里一旦混淆这点，指标偏差不会报错，只会静默出错。
