在SQL里统计行数，几乎是每个开发者一上手就会写的操作。但说到`COUNT(*)`、`COUNT(字段)`的区别，不少人还是有些模糊的。这次就把这个老话题重新捋一遍，说几个容易忽略的细节。

### 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`中至少有一个非空的行数： ```sql SELECT COUNT(*) FROM users WHERE email IS NOT NULL OR phone IS NOT NULL; ``` 如果要统计两者都非空的行： ```sql 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。 举个例子： ```sql 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和语义复杂度。