直接套用 case when + sum 会漏数据，因漏写 else 0 导致 null 被 sum 忽略，使分类总和变小或为 null；正确做法是显式补零：sum(case when type = 'a' then amount else 0 end)。
为什么直接套用 CASE WHEN + SUM 会漏数据？
常见错法是把 CASE WHEN 写在 SUM 外面，比如：SUM(CASE WHEN type = 'A' THEN amount END) —— 这本身没错，但一旦漏写 ELSE 0，NULL 就会被 SUM 忽略，导致该分类总和变小甚至为 NULL。尤其当某类数据完全不存在时，整列结果就是 NULL，而不是预期的 0。
正确做法始终显式补零：
SUM(CASE WHEN type = 'A' THEN amount ELSE 0 END) AS sum_a
-
ELSE 0不可省，这是行转列不出错的底线 - 如果原始
amount本身可能为NULL，需先用COALESCE(amount, 0)处理，再进CASE - 多个分类字段（如
type和status组合）时，CASE条件要写全等价判断，别用模糊匹配
GROUP BY 的字段到底选哪些？
行转列本质是「按维度聚合 + 分类求和」，所以 GROUP BY 必须包含所有非聚合、非 CASE 衍生的字段。例如想按 user_id 和 month 展开各类型金额，GROUP BY user_id, month 就必须完整列出，少一个就会报错或聚合错乱。
典型反例：SELECT user_id, SUM(CASE ...), month FROM t GROUP BY user_id —— month 没进 GROUP BY，MySQL 8.0+ 会报错，旧版可能返回随机值。
- 只要 SELECT 中出现的非聚合字段，全部进
GROUP BY - 别依赖 SQL 模式设置来绕过检查，显式写全最稳妥
- 如果只是临时看总数（不分组），
GROUP BY可以省略，但此时整表只出一行
遇到多层分类（比如 type × status）怎么避免嵌套 CASE？
不要写 CASE WHEN type='A' AND status='paid' THEN ... 堆叠条件——可读性差，维护成本高，还容易漏分支。更清晰的做法是用多维组合键，比如拼成 type || '_' || status（PostgreSQL）或 CONCAT(type, '_', status)（MySQL），再配合 SUM + CASE 拆解。
但更推荐分步：先用子查询或 CTE 固定分类组合，再外层做 CASE 聚合。这样逻辑分离，调试也方便。
- 单层分类（仅
type）直接用多个CASE并列即可 - 两层以上建议用 CTE 预处理，避免
CASE内部逻辑膨胀 - 注意字符串拼接时
NULL会导致整字段为NULL，要用COALESCE包一层
性能瓶颈常卡在哪儿？
最常被忽略的是索引没覆盖 CASE 里用到的字段。比如 CASE WHEN status IN ('paid','refunded')，但表上只有 INDEX(status)，而 status 基数低（如只有 3 个值），这个索引实际帮助很小。真正有效的是联合索引，顺序按 GROUP BY 字段 + CASE 判断字段排列。
- 例如
GROUP BY user_id, month且CASE判type，建索引：INDEX(user_id, month, type) -
SUM本身不慢，慢在扫描全表或临时表排序；加对索引后，执行计划应显示Using index - 如果数据量大且分类多，考虑提前物化中间结果（如每天跑一次汇总表），别每次都实时算
行转列不是语法难题，关键是每个 CASE 分支是否穷尽、GROUP BY 是否严格匹配、索引是否打在刀刃上——这三处任一出问题，结果就不可信，性能也扛不住。
