应使用 SUM(CASE WHEN ... THEN 1 ELSE 0 END) 而非 COUNT(CASE WHEN ... THEN 1 END)，因后者遇不匹配条件返回 NULL 且 COUNT 会跳过，导致缺位 0 变 NULL，引发前端崩溃或计算错误。
直接用 COUNT(*) 加 WHERE 只能处理单组条件；要同时统计多个互斥或交叉的条件（比如“华东区且2023年”“华南区且金额>1w”），必须用 SUM(CASE WHEN ... THEN 1 ELSE 0 END) ——这是跨数据库最稳、逻辑最直白的写法。
为什么不能用 COUNT(CASE WHEN ... THEN 1 END)
看起来简洁，但隐患明显：CASE 不匹配时默认返回 NULL，而 COUNT() 会跳过所有 NULL 值。问题在于——它只统计“满足条件”的行，完全无法表达“不满足时记 0”这个语义。一旦后续要加对比、做百分比或导出到报表，缺位的 0 会变成 NULL，导致前端崩溃或计算错乱。
-
COUNT(CASE WHEN status = 'paid' THEN 1 END)→ 没有 ELSE，结果列里全是数字，但没匹配的行压根不出现在聚合结果里（其实是隐式 NULL，SUM 能感知，COUNT 不能） - 如果字段本身含
NULL（如user_id IS NULL），又没在 CASE 中覆盖，这部分数据会被静默丢弃 - 想在同一行里并列统计“paid”“shipped”“cancelled”，用 COUNT + 多个 CASE 会迫使优化器反复扫描表，性能不如一次 SUM 扫描
MySQL 里别碰 COUNT(IF(...))
IF() 是 MySQL 特有函数，看着短，但容易踩空值坑。最常见错误是写成 COUNT(IF(status='active', 1, NULL)) ——这其实等价于 COUNT(*) 对 active 行计数，看似对，但一旦改成 COUNT(IF(status='active', 1, 0))，0 是非 NULL 值，COUNT() 就把所有行都算进去了。
- 正确姿势只有两个：
SUM(IF(condition, 1, 0))或更通用的SUM(CASE WHEN condition THEN 1 ELSE 0 END) -
IF()在 PostgreSQL / SQL Server / Oracle 中根本不存在，换库就得重写 - 哪怕只跑在 MySQL 上，也建议统一用
CASE WHEN：语义清晰、分支易扩展、团队协作时没人猜你 IF 里漏了啥
多条件并列统计的实际写法
核心就一条：每个条件独立一个 SUM(CASE WHEN ... THEN 1 ELSE 0 END)，堆在 SELECT 里。不要试图在一个 CASE 里塞太多分支，可读性和维护性会断崖下跌。
- 统计订单状态分布：
SUM(CASE WHEN status = 'pending' THEN 1 ELSE 0 END) AS pending_count - 组合条件（AND）直接写 inside WHEN：
SUM(CASE WHEN region = 'east' AND YEAR(order_date) = 2023 THEN 1 ELSE 0 END) - OR 条件同理：
SUM(CASE WHEN status = 'shipped' OR status = 'delivered' THEN 1 ELSE 0 END) - 注意字符串要用单引号：
'east'，双引号在部分数据库（如 PostgreSQL）里代表标识符，不是字符串字面量
GROUP BY 场景下容易忽略的 NULL 分组
当按某字段分组再条件计数时，如果该字段存在 NULL 值（比如 category IS NULL），GROUP BY category 会把所有 NULL 归为一组。但很多人写 COUNT(CASE WHEN ...) 却没意识到：这一组里的条件判断可能全不命中，结果就是 0 还是 NULL？取决于你 CASE 里有没有 ELSE 0。
- 没写 ELSE → 这组的计数值是
NULL（因为所有 CASE 都返回 NULL，COUNT 跳过，SUM 得 NULL） - 写了 ELSE 0 → 这组显示为 0，语义明确
- 更麻烦的是：有些业务要求把 NULL 分组单独标为 “unknown”，那就得提前用
COALESCE(category, 'unknown')处理，而不是靠 CASE 补救
真正难的不是写对一行 SQL，而是确保所有分支都被显式覆盖——尤其是 ELSE 0 和 NULL 字段的分组行为。漏掉一个，线上报表就少一块数据，还查不出原因。
