在MySQL中，用SUM(IF(condition,1,0))统计分组内满足条件的行数最准确，因其确保每行贡献0或1；COUNT(IF())易因NULL处理导致计数错误。
用 SUM(IF()) 统计分组内满足条件的行数
直接说结论：在 MySQL 中，SUM(IF(condition, 1, 0)) 是最常用、最直观的分组条件计数写法，它本质是把布尔判断转为数值再累加。
为什么不用 COUNT(IF())？因为 COUNT() 会忽略 NULL，而 IF(condition, 1, NULL) 在不满足时返回 NULL，导致漏计；但 IF(condition, 1, 0) 确保每行都贡献 0 或 1，SUM 累加结果才准确。
常见错误现象：COUNT(IF(status='active', 1, NULL)) 看似合理，实则等价于 COUNT(*) 对 status='active' 的行计数——但一旦写成 COUNT(IF(status='active', 1, 0)) 就错了：因为 0 是非空值，COUNT 会把所有行都算进去。
-
IF()必须返回数值（推荐1和0），不能依赖COUNT去“过滤” - MySQL 5.7+ 支持，8.0 同样适用；MariaDB 也支持；PostgreSQL 不支持
IF()，得改用CASE WHEN - 性能上和
CASE WHEN几乎无差别，优化器通常能等价处理
替代写法：CASE WHEN 更通用，跨数据库友好
如果你的 SQL 要跑在 PostgreSQL、SQL Server 或 Oracle 上，IF() 不存在，必须用 CASE WHEN。它语义更明确，也更容易嵌套复杂条件。
示例：统计每个部门中薪资超 10000 的人数
SELECT dept, SUM(CASE WHEN salary > 10000 THEN 1 ELSE 0 END) AS high_earners FROM employees GROUP BY dept;
注意点：
-
CASE WHEN的ELSE 0不能省——缺了就默认为NULL，SUM(NULL)不影响结果，但逻辑不清晰，易被后续维护者误改 - 不要写成
COUNT(CASE WHEN ... THEN 1 END)：虽然也能工作（因为THEN 1后没ELSE默认NULL），但可读性差，且一旦补上ELSE 1就全乱了 - 多个条件并列统计？直接叠加多个
SUM(CASE...)即可，别试图在一个CASE里塞太多分支
SUM vs COUNT：别被函数名带偏
关键不是“该用哪个函数”，而是“你想统计什么”。COUNT 数的是**非空值的个数**，SUM 算的是**数值总和**。条件计数本质上是“对每行打 1 分或 0 分，再求和”，所以 SUM 更贴切。
反例场景：想查每组里 email 不为空的用户数
- ✅ 正确：
COUNT(email)—— 利用COUNT天然忽略NULL的特性 - ✅ 也可：
SUM(CASE WHEN email IS NOT NULL THEN 1 ELSE 0 END) - ❌ 错误：
COUNT(IF(email IS NOT NULL, 1, 0))—— 把0当作有效计数项，结果比实际多
简单记：纯非空判断用 COUNT(列名) 最轻量；带逻辑表达式（如范围、字符串匹配、多条件组合）必须用 SUM(CASE...) 或 SUM(IF())。
GROUP BY 后 WHERE 和 HAVING 的分工别搞混
容易踩的坑：把条件写在 WHERE 里，却想统计分组后的条件数量。例如：“只看平均薪资 > 8000 的部门，并统计其中高级员工人数”——这里有两个层级的过滤。
正确拆解：
-
WHERE先筛原始行（比如WHERE job_level IN ('senior', 'lead')）——这会影响所有聚合结果的基数 - 真正要“在每组内判断某条件是否成立”，必须写进
SUM(IF())或CASE的内部表达式里 -
HAVING是对聚合结果过滤（如HAVING SUM(IF(role='manager', 1, 0)) > 0），不能用来替代行级条件判断
一句话：条件逻辑在 SELECT 里的 IF 或 CASE 中，不在 WHERE 里——除非你本意就是先剔除整批数据。
