应统一使用SUM(CASE WHEN ... THEN 1 ELSE 0 END)替代COUNT(IF(...))或COUNT(CASE ...)，因其对NULL处理明确、支持加权计数、逻辑清晰且无兼容性问题。
MySQL中用SUM(CASE WHEN ...)替代多个COUNT(IF(...))
直接上结论：想在一个SELECT里统计多个条件下的行数，SUM(CASE WHEN ... THEN 1 ELSE 0 END)比COUNT(IF(..., 1, NULL))更稳妥，尤其当字段可能为NULL时——COUNT会跳过NULL，而SUM明确控制加什么、不加什么。
常见错误是写成COUNT(CASE WHEN ... THEN 1 END)，这其实等价于COUNT(1)只统计“满足条件的非NULL分支”，但漏掉ELSE时默认为NULL，结果没错；可一旦需要统计“不满足条件”的数量，就容易混乱。用SUM逻辑更直白。
-
SUM天然支持加权计数（比如“满足A加1，满足B加2”） - 所有分支必须显式覆盖（
ELSE 0不能省，否则NULL参与SUM会让整列变NULL） - MySQL 5.7+ 和 8.0 都完全支持，无兼容性问题
统计多状态订单数量：真实场景写法
假设订单表orders有字段status（值为'pending'、'shipped'、'cancelled'），要一行返回三类数量：
SELECT SUM(CASE WHEN status = 'pending' THEN 1 ELSE 0 END) AS pending_count, SUM(CASE WHEN status = 'shipped' THEN 1 ELSE 0 END) AS shipped_count, SUM(CASE WHEN status = 'cancelled' THEN 1 ELSE 0 END) AS cancelled_count FROM orders;
注意点：
- 别写
ELSE NULL——SUM(NULL, 1, 1)结果是2，但SUM(NULL, NULL, 1)仍是1；可一旦全不匹配，SUM()返回NULL而非0，加ELSE 0保底 - 条件顺序不影响结果，但建议把高频值放前面（对性能几乎无影响，纯为可读）
- 如果
status有索引，这个查询能走索引范围扫描，比子查询或多次COUNT(*) WHERE快得多
和COUNT + IF混用时的坑
有人习惯写COUNT(IF(status='pending', 1, NULL))，它确实等价于上面的SUM(...)，但隐患在嵌套或组合时：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
COUNT(IF(...))无法直接表达“满足A时不计数，满足B时计2次”这种逻辑 - 若误写成
COUNT(IF(status='pending', 1, 0))，0不是NULL，COUNT会把它当有效值计进去，结果虚高 - 混合使用
SUM(CASE)和COUNT(IF)易导致语义割裂，团队维护成本上升
简单记：只要目标是“按条件累加数值”，统一用SUM(CASE ...)，别切到COUNT逻辑里。
带GROUP BY的分组多条件统计
统计每个用户各类订单数，只需加GROUP BY user_id：
SELECT user_id, SUM(CASE WHEN status = 'pending' THEN 1 ELSE 0 END) AS pending, SUM(CASE WHEN status = 'shipped' THEN 1 ELSE 0 END) AS shipped FROM orders GROUP BY user_id;
关键提醒：
-
GROUP BY字段必须出现在SELECT列表（除非用ANY_VALUE()，但不推荐） - 聚合函数里的
CASE不能引用外部GROUP BY未包含的非聚合字段，否则报错sql_mode=only_full_group_by - 如果要过滤分组后结果（比如只看“待处理数＞5的用户”），必须用
HAVING，不能用WHERE
最常被忽略的是ELSE 0——少写这一句，遇到全不匹配的分组，那一列就是NULL，后续做报表或导出时容易崩掉。
