应使用sum(case when ... then 1 else 0 end)而非count(if())，因sum显式将每行映射为0或1再求和，语义清晰、可扩展（支持加权）、跨库兼容；而count(if())依赖mysql特有函数且易误写为count(if(...,1,0))导致全行计数错误。
为什么用 SUM(CASE WHEN) 而不是 COUNT(IF())
因为 COUNT() 会跳过 NULL，而你真正需要的是“不满足条件时记为 0”，不是“直接忽略”。比如统计订单状态为 'pending' 的数量，若写成 COUNT(CASE WHEN status = 'pending' THEN 1 END)，那所有非 pending 行都贡献 NULL，COUNT 直接无视——结果没错，但逻辑脆弱：一旦你要加“非 pending”的计数，就得另起炉灶，容易漏分支或对不齐条件。
SUM(CASE WHEN ... THEN 1 ELSE 0 END) 显式控制每行贡献值，语义清晰、可扩展性强。它天然支持加权（比如 THEN 2），也兼容所有主流 SQL 引擎（MySQL 5.7+、8.0、PostgreSQL）。
- 别信
COUNT(IF(status='pending', 1, NULL))——IF()是 MySQL 特有，跨库不通用 -
COUNT(CASE WHEN ... THEN 1 END)看似简洁，但分支没覆盖时默认NULL，后续加新状态易出错 - 如果字段本身可能为
NULL（如status IS NULL），= 'pending'永远不成立，得额外补OR status IS NULL判断
怎么写才不会返回 NULL 而是 0
ELSE 0 不是可选项，是必填项。漏掉它，只要某分组里没有任何一行命中 THEN 分支，整列 SUM() 就变成 NULL——不报错，但数值断崖式消失，排查极难。
错误示范：SUM(CASE WHEN status = 'shipped' THEN 1 END) → 全部不匹配时返回 NULL；正确写法：SUM(CASE WHEN status = 'shipped' THEN 1 ELSE 0 END) → 确保每行至少贡献 0。
-
ELSE NULL和不写ELSE效果一样，都等于放任NULL进入求和 - 别想靠外层
COALESCE(SUM(...), 0)补救——这是掩盖问题，不是解决问题 - 多个状态并列时，每个
SUM(CASE...)都必须独立带ELSE 0，不能共用一个兜底
多状态并列统计的写法与性能要点
要同时统计 'pending'、'shipped'、'cancelled' 三类数量，就老老实实写三个并列的 SUM(CASE WHEN)，别嵌套、别复用变量、别试图“优化”成一个 CASE 套三层。
数据库优化器能并行处理这些独立分支，执行计划里只扫一次表；而嵌套写法（如 CASE WHEN ... THEN ... ELSE CASE WHEN ...）不仅难读，还可能干扰索引下推。
- 高频状态建议放前面（纯为可读性，对性能几乎无影响）
- 如果
status字段有索引，这类查询大概率走索引范围扫描，比多次SELECT COUNT(*) WHERE status = 'X'快得多 - 避免在
CASE里调函数，比如UPPER(status) = 'PENDING'—— 索引失效
GROUP BY 场景下怎么保证各指标对齐
当按部门、时间、地区等维度分组时，所有 SUM(CASE WHEN) 必须共享同一个 GROUP BY 字段列表，且 SELECT 中所有非聚合字段都得出现在 GROUP BY 中——MySQL 5.7 启用 ONLY_FULL_GROUP_BY 后，这点和 PostgreSQL 一致。
常见翻车点：在 CASE 里引用了未出现在 GROUP BY 中的字段（比如 user_id），或者误把条件写在 WHERE 里导致部分分组被整体过滤掉。
- 想排除某些数据？先用
WHERE过滤（如WHERE create_time >= '2026-01-01'），再做CASE统计 - JOIN 后字段可能为
NULL，比如左连用户表后user.status为空，= 'active'仍不成立，需提前判断user.status IS NOT NULL AND user.status = 'active' - 字段名带空格或关键字？用反引号包裹，如
`order status`，否则语法报错
ELSE 0 的缺失——它不报错，不告警，只悄悄让数字变 NULL，等你导出报表发现某列全空，再回查 SQL 已经耗掉半天。
