sum(case when)是条件聚合而非行过滤，它不减少行数，仅改变组内求和逻辑；需用where真正剔除记录，多条件对比时才用case when，并务必补else 0以防null导致结果异常。
SQL里用SUM(CASE WHEN)不是过滤，是条件聚合
很多人写 SUM(CASE WHEN status = 'done' THEN amount END) 是想“排除未完成的记录”，但其实它没过滤任何行——只是对不满足条件的行贡献 NULL，而 SUM() 会自动跳过 NULL。真正被“忽略”的不是记录，是那些没进 THEN 分支的值。
常见错误现象：
• 结果比预期小（漏加了 ELSE 0，导致 NULL 被跳过，但你以为它该算 0）
• 和 WHERE status = 'done' 的结果不一致（后者真过滤行，前者仍保留其他行参与 GROUP BY）
- 要用条件聚合，就接受它不改变行数——它只改变每组内某个字段的求和逻辑
- 如果需要完全剔除某些记录再聚合，优先用
WHERE；只有当同一组里要对比多个条件（比如同时算 done/undone 的 sum）才必须用CASE WHEN - 记得补
ELSE 0：否则SUM(CASE WHEN ... THEN x)等价于SUM(CASE WHEN ... THEN x ELSE NULL)，容易误判为“没数据”
GROUP BY 存在时，CASE WHEN 必须和分组逻辑对齐
一旦用了 GROUP BY，CASE WHEN 里的字段如果不在分组键中，又没被聚合，就会报错（比如 PostgreSQL 或 MySQL 严格模式下的 column must appear in the GROUP BY clause）。
使用场景：按部门统计“已付款订单金额”和“总订单金额”两个指标。
- 错误写法：
SUM(CASE WHEN payment_status = 'paid' THEN order_amount END) AS paid_sum，但payment_status没出现在GROUP BY且没被聚合 → 报错 - 正确做法：要么把
payment_status加进GROUP BY（但这会拆散分组），要么确认它只是计算上下文里的字段，不参与分组——此时它必须是每个分组内确定的值（比如来自关联表的稳定属性），或包裹在聚合函数里（如MAX(payment_status)） - 更安全的写法是提前在子查询或 CTE 中处理好状态字段，避免在聚合层暴露非分组列
NULL 和 0 在 SUM(CASE WHEN) 里的实际影响
SUM() 遇到 NULL 直接忽略，遇到 0 会累加。这看起来没区别，但在空集、类型隐式转换、前端展示时表现完全不同。
- 没匹配到任何
WHEN条件 → 整个CASE返回NULL→SUM返回NULL（不是 0）→ 前端可能显示为空或报错 - 显式写
ELSE 0→ 返回 0 → 安全可运算 - 如果
amount字段本身可为NULL，THEN amount仍可能产出NULL，建议套一层COALESCE(amount, 0) - 示例：
SUM(CASE WHEN flag = 1 THEN COALESCE(value, 0) ELSE 0 END)才真正“兜底”
性能：CASE WHEN 不会提前终止扫描，别指望它替代 WHERE
数据库优化器通常不会因为写了 CASE WHEN 就跳过不满足条件的行。它仍然要读取所有原始行，再逐行判断条件——尤其是当聚合字段没索引、或条件涉及函数时，开销和全表扫描接近。
- 想提速？先把筛选逻辑下沉到
WHERE：比如先WHERE status IN ('done', 'cancelled')再聚合，比在CASE里写一堆分支快得多 -
CASE WHEN适合做“一扫多算”，不适合做“少扫少算” - 如果条件分支特别多（>5 个），考虑是否该拆成多个聚合查询，或用
FILTER（PostgreSQL）或PIVOT（SQL Server）替代，语义更清晰且可能触发更好执行计划
最常被忽略的是：CASE WHEN 的执行时机在 WHERE 之后、GROUP BY 之前，但它不减少中间结果集大小。想省资源，得从源头砍行数，而不是在聚合层“假装忽略”。
