GROUP BY 无法按逻辑条件分组，只能按字段值分组；SUM(CASE WHEN...) 是标准解法，需确保THEN后为数值字段、显式写ELSE 0，并注意嵌套CASE的END配对与索引优化。
为什么直接用 GROUP BY 无法满足“按条件动态求和”
当你需要对同一列数据，在不同条件下分别统计（比如：统计订单中“已支付”金额、“未支付”金额、“退款中”金额），GROUP BY 本身只能按字段值分组，不能按逻辑条件分组。强行用多个 WHERE 分开查再 UNION ALL，效率低、难维护，还容易漏掉零值分组。
SUM(CASE WHEN ...) 是最常用且可靠的条件聚合写法
核心思路是：在 SUM() 内部用 CASE WHEN 把目标字段“转换”成条件匹配时的数值、不匹配时为 0 或 NULL（SUM 会自动忽略 NULL）。
常见错误是写成 SUM(CASE WHEN status = 'paid' THEN amount END) —— 这里 ELSE 缺失，没匹配的行返回 NULL，虽不影响结果但可读性差；更糟的是误写成 SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END)，这算的是笔数而非金额。
- 必须确保
THEN后面是你要累加的数值字段（如amount），不是常量 - 显式写
ELSE 0比留空更安全，避免因 NULL 导致调试困惑 - 多个条件并列时，每个
SUM(CASE ...)独立计算，互不影响
SELECT
user_id,
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_sum,
SUM(CASE WHEN status = 'refunding' THEN amount ELSE 0 END) AS refunding_sum,
SUM(CASE WHEN status IN ('paid', 'shipped') THEN amount ELSE 0 END) AS shipped_or_paid_sum
FROM orders
GROUP BY user_id;
嵌套 CASE WHEN 在 SUM 里要小心优先级和括号
当条件本身有层级（比如先看状态、再看时间），容易把逻辑写错位置。典型错误是把外层 CASE 的 END 放错位置，导致 SQL 解析失败或语义偏离。
例如想统计“2024年已支付订单金额”和“其他所有订单金额”，不能写成：
SUM(CASE WHEN status = 'paid' THEN (CASE WHEN created_at >= '2024-01-01' THEN amount ELSE 0 END))
这里少了一个 END，正确写法必须严格配对：
SUM(CASE WHEN status = 'paid' THEN CASE WHEN created_at >= '2024-01-01' THEN amount ELSE 0 END ELSE 0 END)
- 每层
CASE必须有独立的WHEN/ELSE/END - 建议缩进书写，或拆成子查询——复杂逻辑硬塞进一个
SUM容易出错 - 注意数据库对嵌套深度的限制（如 MySQL 默认支持 61 层，但实际超过 3 层就该考虑重构）
性能和兼容性要注意这些细节
SUM(CASE WHEN ...) 是标准 SQL，主流数据库（PostgreSQL、MySQL 5.7+、SQL Server、Oracle、SQLite3）都支持，但部分老版本或特殊引擎可能不优化索引使用。
- 如果条件字段（如
status）没有索引，大表上GROUP BY+ 多个CASE可能全表扫描——优先给过滤字段建索引 - MySQL 8.0+ 和 PostgreSQL 支持
FILTER子句（如SUM(amount) FILTER (WHERE status = 'paid')），语义更清晰，但兼容性不如CASE - 避免在
CASE中调用函数（如DATE(created_at)）做判断，会导致索引失效；应提前在 WHERE 中过滤或用生成列
真正麻烦的不是语法写不对，而是条件分支越来越多后，没人敢动那段 SUM(CASE ...) —— 它成了报表 SQL 里的“祖传代码”。拆成 CTE 或视图，比堆砌 CASE 更可持续。
