count(*)统计行存在性，count(列)统计该列非null值数量；前者只判断行是否在结果集中，后者必须逐行判空且不可绕过，语义不同导致分页、校验等场景易出错。

COUNT(*) 统计的是行存在性，COUNT(列) 统计的是列非 NULL 性

这是根本区别，不是性能或写法偏好问题。COUNT(*) 只关心“这一行在结果集中是否存在”，哪怕所有字段都是 NULL，只要它被 WHERE、JOIN 或子查询保留下来，就算 1 行。而 COUNT(列名) 必须逐行读取该列值，遇到 NULL 就跳过——这个判断是强制的、不可绕过、不因索引或优化器改变。

常见错误现象：COUNT(*) 返回 1000，COUNT(email) 返回 823 → 说明有 177 行的 email 是 NULL。如果用后者做分页总数或数据校验，逻辑就错了。

容易踩的坑：

• 误以为 id 是主键就一定非 NULL → 若建表时没加 NOT NULL 约束，INSERT 时漏传或显式插入 NULL，COUNT(id) 就会少算
• 在 LEFT JOIN 后用 COUNT(users.name) 想统计“有多少订单关联了用户”，结果其实是“有多少订单关联了非空 name 的用户”，语义已偏移
• ''（空字符串）、0、false 都算非 NULL，会被 COUNT(列名) 计入；只有真正的 NULL 被跳过

COUNT(*) 在无 WHERE 时可能走元数据或最小索引扫描，COUNT(列) 往往要读实际值

MySQL InnoDB 8.0+ 对 COUNT(*) 有专属路径：若查询无 WHERE、GROUP BY、HAVING，它会选最小索引（通常是主键）只扫叶子节点，不回表、不解码字段。而 COUNT(列名) 即使该列有索引，只要允许 NULL，优化器仍需确认每条索引项对应的真实行中该列是否为 NULL，大概率触发回表或全表扫描。

性能差异真实存在，但取决于两个硬条件：

• 该列是否定义了 NOT NULL 约束？没加就别指望跳过判空
• 该列是否有索引？无索引 + 允许 NULL → 几乎必然全表扫描 + 列解码
• NULL 比例高（如 >50%）→ 即使有索引，遍历成本也常高于扫主键索引（因二级索引更宽、页更多）

COUNT(1) 和 COUNT(*) 执行计划几乎一致，别为“看起来快”换写法

MySQL 官方明确说明：COUNT(*) 和 COUNT(1) 在 InnoDB 中被同等优化，执行计划相同，耗时差异通常在 ±0.5ms 内，远小于缓冲池抖动影响。所谓“COUNT(1) 更快”是过时经验，尤其在 InnoDB 引擎下无效。

真正该盯住的不是括号里填什么，而是：

• 业务到底要“总行数”还是“某列有效值数量”？语义错，再快也没用
• 查 COUNT(*) - COUNT(列名) 看 NULL 占比，再决定是否加 NOT NULL 约束或索引
• 带 WHERE 条件时，COUNT(*) 走不走索引，取决于是否有匹配的联合索引，和写法无关

JOIN 场景下 COUNT(*) 的结果不等于左表原始行数

SELECT COUNT(*) FROM orders LEFT JOIN users ON orders.user_id = users.id 返回的是连接后产生的总行数——如果某订单匹配了 3 个用户，它就被算 3 次。这不是 bug，是 SQL 标准定义的行为。

想统计“原始订单数”，不能靠函数选择，必须用明确语义的写法：

• COUNT(DISTINCT orders.id)（注意去重开销）
• (SELECT COUNT(*) FROM orders) 子查询（隔离左表）
• 绝不能用 COUNT(users.id) 代替，那统计的是“成功关联且 users.id 非 NULL 的订单数”，既不是左表数，也不是关联数

最容易被忽略的一点：NULL 处理发生在 WHERE 和 GROUP BY 之后，COUNT(列名) 反映的是当前结果集里该列的非空数量，不是原始表分布。一旦混淆，偏差不会报错，只会静默出错。