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(列名) 反映的是当前结果集里该列的非空数量，不是原始表分布。一旦混淆，偏差不会报错，只会静默出错。
