因为SUM(CASE WHEN...)在单次表扫描中完成条件判别与累加，避免多次JOIN子查询引发的重复扫描、临时表及嵌套循环，尤其在10万行以上、多分类场景下优势显著；前提为所有字段源自同一表同逻辑行。
为什么直接用 SUM(CASE WHEN ...) 比 JOIN 多次子查询快
因为 SUM 是聚合函数，配合 CASE WHEN 能在单次扫描中完成条件判别与累加，避免多次全表扫描或临时表生成。尤其当源表行数超 10 万、分类维度 ≥ 3 个时，性能差距明显——JOIN 子查询可能触发嵌套循环，而 SUM(CASE WHEN ...) 常被优化器转为向量化条件累加。
关键前提是：所有目标列都来自同一张表的同一行逻辑（即“行内多条件判别”，非跨行关联）。
- 适用场景：
orders表中按status统计不同状态订单金额总和 - 不适用场景：需关联
users表获取城市信息后再分组统计——这时得先JOIN，再SUM(CASE...) - 注意：
CASE WHEN必须有ELSE 0（或NULL），否则空值参与SUM会导致整列结果为NULL
CASE WHEN 中 NULL 和 0 的选择影响最终 SUM 结果
SUM 会自动忽略 NULL，但不会忽略 0。所以写法差异直接影响语义：
SUM(CASE WHEN status = 'paid' THEN amount ELSE NULL END) -- 只累加 paid 行，其余不参与
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) -- 所有行都参与，未匹配的加 0
两者结果通常一致，但若外层有 HAVING COUNT(*) > 10 这类过滤，或后续用 COALESCE(SUM(...), 0)，行为就不同了。
- 推荐统一用
ELSE 0：语义清晰，避免因某组全不匹配导致SUM返回NULL - 如果字段本身允许
NULL（如amount可为空），记得先COALESCE(amount, 0) - MySQL 8.0+ 和 PostgreSQL 支持
FILTER语法（如SUM(amount) FILTER (WHERE status = 'paid')），更简洁，但兼容性差
GROUP BY 字段漏写或错写导致行转列结果坍缩
行转列本质是“按某维度分组，再对每组横向展开多个统计列”。一旦 GROUP BY 缺失或粒度太粗，就会把本该分开的行合并，造成数据覆盖或归零。
常见错误：
- 只写
GROUP BY user_id，但原始数据还有month字段要保留 → 应写GROUP BY user_id, month - 误把条件字段（如
status）放进GROUP BY→ 每个status单独一行，失去“一行动态展示多状态”的效果 - 用字符串拼接伪造分组（如
GROUP BY CONCAT(user_id, '_', region)）→ 索引失效，且易因空值崩掉
验证方法：去掉 SUM(CASE...)，只查 SELECT user_id, status, amount FROM orders LIMIT 5，对照分组字段是否能唯一确定每行语义。
带小数精度的金额列用 SUM(CASE...) 后出现浮点误差
如果 amount 是 FLOAT 或 DOUBLE 类型，SUM 结果可能出现 99.9999999999999 这类显示异常。这不是 CASE WHEN 的问题，而是底层浮点存储缺陷。
- 修复方式：显式转为定点数，如
SUM(CAST(CASE WHEN ... THEN amount ELSE 0 END AS DECIMAL(12,2))) - 建表时就应定义为
DECIMAL(12,2)，而非FLOAT - PostgreSQL 用户可直接用
ROUND(SUM(...), 2)，但注意ROUND是四舍五入，不是截断；若需严格截断，用TRUNC(SUM(...), 2)
这个细节常被忽略，直到财务对账时发现 0.01 元差异才排查到——其实从源头定义类型就开始埋雷了。
