count(*) 是最安全高效的计数方式，应直接跟在 where 后；错误用法如 count(status='active') 会因布尔转数值导致结果失真；多条件统计须用 count(case when...then 1 end)，且不可写 else 0；分组占比计算需确保分子分母同级作用域。
WHERE 后直接跟 COUNT(*) 是最常用也最安全的写法
想统计“状态为 active 的用户有多少”，直接写 SELECT COUNT(*) FROM users WHERE status = 'active' 就行。数据库会在扫描时先过滤，再计数，语义清晰、性能好、不会出错。
常见错误是把条件塞进 COUNT() 里，比如 COUNT(status = 'active') —— 这在 MySQL 里可能“碰巧”返回结果，但本质是把布尔表达式当数值（true=1, false=0），然后 COUNT() 对所有非 NULL 值计数，结果其实是总行数，不是条件满足数。
-
COUNT(*)统计所有被WHERE筛出来的行，不管列值是否为 NULL -
COUNT(列名)在WHERE之后执行，只统计该列非 NULL 的行——比如COUNT(email) WHERE status = 'active'，会漏掉那些活跃但没填邮箱的用户 - 如果
WHERE没匹配到任何行，COUNT(*)返回0，不是NULL，可直接参与后续计算
COUNT(CASE WHEN ...) 用于单行内多条件并行统计
当你要在同一查询里算“已支付订单数”“退款订单数”“待发货订单数”，别写三个带 WHERE 的子查询——用 COUNT(CASE WHEN ... THEN 1 END) 一次扫表全搞定。
关键点：COUNT() 只统计非 NULL 值，所以 CASE 必须让不满足条件的分支返回 NULL（显式写 ELSE NULL 或直接省略 ELSE）。写成 ELSE 0 就错了，因为 0 是非 NULL 值，会被计进去。
- 正确：
COUNT(CASE WHEN status = 'paid' THEN 1 END) - 错误：
COUNT(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) - 如果字段本身可能为 NULL（比如
user_id），且你希望把user_id IS NULL的行也纳入某一分组统计，得在CASE里显式覆盖，否则它们会被当作NULL排除
GROUP BY 场景下，分子分母必须同级作用域
算“每个部门里薪资超 15000 的员工占比”，不能先 WHERE salary > 15000 再分组——那样分母变成“高薪员工总数”，结果全是 1.0。
正确做法是所有行都参与 GROUP BY，仅在分子用 CASE WHEN 判定，分母用 COUNT(*) 表示该部门全部人数：
SELECT department,<br> COUNT(CASE WHEN salary > 15000 THEN 1 END) * 1.0 / COUNT(*) AS high_salary_ratio<br>FROM employees<br>GROUP BY department;
- 乘
1.0是为了触发浮点除法，避免整数除法截断（如3/5 = 0） - 也可以用
AVG(CASE WHEN salary > 15000 THEN 1.0 ELSE 0 END)，语义更直白，且空分组时返回NULL而非除零错误 -
HAVING不能替代WHERE来筛原始行——它只能过滤聚合后的结果，比如HAVING COUNT(*) > 10
COUNT(*) 性能通常优于 COUNT(列名)，但有前提
多数情况下，COUNT(*) 更快，尤其当表有主键或非空索引时，优化器可能直接走索引统计，不用读行数据。而 COUNT(列名) 得检查该列每行是否为 NULL，开销略大。
但这个优势依赖数据库实现和索引情况。如果列上有二级索引且覆盖查询（比如 COUNT(status)，而 status 字段有索引），某些引擎也能高效执行。盲目认为 “COUNT(*) 一定最快” 可能误判。
- 没有索引的大表上，
COUNT(*)和COUNT(列名)都要全表扫描，差别不大 -
COUNT(DISTINCT 列名)代价显著更高，涉及去重逻辑，大数据量慎用 - 真正影响性能的是
WHERE条件能否命中索引——比起纠结用哪个COUNT，优先确保过滤字段有索引
实际写的时候，最容易被忽略的是：分母到底指哪一部分。WHERE、GROUP BY、窗口函数的作用层级不同，一不留神就让比例算歪了。别凭感觉写，先画清楚逻辑边界——哪些行参与分组，哪些行参与分子判定，哪些行构成分母。
