count(*)统计所有行（包括含null的行），count(字段名)只统计该字段非null的行；前者用于统计物理行数，后者用于统计有效业务值数量。
COUNT(*) 和 COUNT(字段名) 的行为差异
直接说结论：COUNT(*) 统计所有行（包括含 NULL 的行），而 COUNT(字段名) 只统计该字段非 NULL 的行。如果你要“统计非空数据的实际行数”，必须用 COUNT(字段名)，且字段名不能是 *。
常见误解是以为 COUNT(*) 会跳过 NULL —— 它不会。哪怕整行全是 NULL，COUNT(*) 也会计 1。
-
COUNT(*)：按行计数，无视任何列值 -
COUNT(email)：只算email IS NOT NULL的行 -
COUNT(COALESCE(email, phone))不合法 ——COUNT不接受表达式（除非是标准 SQL:2003+ 的某些实现，但 MySQL/PostgreSQL/SQL Server 均不支持）
多字段联合非空行怎么统计？
没有原生的 COUNT 语法能直接统计“至少一个字段非空”或“所有字段都非空”的行数。得靠条件转换。
比如想统计 email 和 phone 中至少有一个非空的行数：
SELECT COUNT(*) FROM users WHERE email IS NOT NULL OR phone IS NOT NULL;
如果要统计两者都非空的行：
SELECT COUNT(*) FROM users WHERE email IS NOT NULL AND phone IS NOT NULL;
- 别写
COUNT(email AND phone)—— 这是语法错误，AND是逻辑运算符，不能放进COUNT() - 别依赖
COUNT(email, phone)—— 多参数COUNT在标准 SQL 和主流数据库中不存在 - 需要聚合前过滤，就用
WHERE；需要在同一查询里分维度统计，就用SUM(CASE WHEN ... THEN 1 ELSE 0 END)
GROUP BY 场景下 COUNT(字段) 的陷阱
在 GROUP BY 查询里，COUNT(字段名) 对每组分别跳过 NULL，这本身没问题。但容易出错的是：你可能以为某组没结果是因为数据为空，其实是该组里对应字段全为 NULL，导致 COUNT(字段) 返回 0，而非 NULL。
例如：
SELECT dept, COUNT(manager_name) FROM staff GROUP BY dept;
若某部门所有 manager_name 都是 NULL，这行仍会返回 (dept_x, 0)，不是被过滤掉，也不是 NULL。
-
COUNT永远返回INT，不会是NULL - 想区分“无数据”和“有数据但全空”，得额外加
COUNT(*)对比：COUNT(*) > 0 AND COUNT(field) = 0 - 聚合函数对空组（如 LEFT JOIN 后右表无匹配）返回
0，不是NULL，这点常被忽略
性能与索引影响
COUNT(*) 在多数引擎（如 InnoDB）上可走索引元数据或最小索引树扫描，速度较快；而 COUNT(字段名) 必须实际读取该字段值判断是否为 NULL，尤其当字段没索引、或类型是 TEXT/JSON 时，I/O 开销明显上升。
- 如果字段允许
NULL且没索引，COUNT(字段)可能比COUNT(*)慢几倍 - 唯一能加速
COUNT(字段)的方式是给该字段建普通索引（不含NULL的索引条目会被跳过，但引擎仍需检查是否为NULL） - MySQL 8.0+ 对
COUNT(字段)在覆盖索引下有优化，但 PostgreSQL 和 SQL Server 仍基本依赖全字段扫描
真正要注意的不是语法怎么写，而是你到底想统计“物理行数”还是“有效业务值数量”——前者用 COUNT(*)，后者必须明确指定字段，并接受它带来的 I/O 和语义复杂度。
