CASE WHEN 配 SUM 是最稳妥横表方案，因其跨库兼容、逻辑透明，能精准映射分类值到列并聚合收拢；需覆盖全取值、写 ELSE 0、配 GROUP BY，语义匹配才不致失真。
为什么直接用 CASE WHEN 配 SUM 是最稳妥的横表方案
因为纵表转横表本质是“分类聚合+列展开”，而 CASE WHEN 能精准控制每个分类值映射到哪一列，SUM（或 MAX/COUNT）负责把同一分组下分散的行收拢成单值。比起 PIVOT（SQL Server/Oracle 专属）、GROUP_CONCAT（MySQL）或窗口函数，它跨数据库兼容性最好，逻辑也最透明。
常见错误现象：CASE WHEN 忘写 ELSE 0 导致 NULL 参与 SUM 后整列为 NULL；漏加 GROUP BY 导致只返回一行；分类字段值含空格或特殊字符没加引号导致语法报错。
- 必须对分类字段做明确分组——
GROUP BY的字段应包含所有非聚合列（如用户ID、日期等） -
CASE WHEN的条件要覆盖全部可能取值，或用ELSE 0拦住未知值，避免聚合后列丢失 - 若原始值是字符串（如“完成”“进行中”），用
MAX或MIN更合适；若是数值（如订单金额、评分），SUM才有意义
怎么写一个带动态分类的 CASE WHEN + SUM 横表查询
假设有一张订单状态流水表 order_status_log，字段为 order_id、status（值为 'pending'/'shipped'/'delivered'）、amount。想按订单统计各状态的总金额：
SELECT order_id, SUM(CASE WHEN status = 'pending' THEN amount ELSE 0 END) AS pending_amount, SUM(CASE WHEN status = 'shipped' THEN amount ELSE 0 END) AS shipped_amount, SUM(CASE WHEN status = 'delivered' THEN amount ELSE 0 END) AS delivered_amount FROM order_status_log GROUP BY order_id;
注意点：
- 每个
CASE WHEN必须对应一个别名（AS xxx），否则列名不可读 -
ELSE 0不可省略——NULL 和数字相加结果仍是 NULL，会污染整列求和 - 如果某订单没有 'shipped' 记录，对应列就是 0，不是 NULL，便于后续计算或导出
遇到分类值不固定时，还能用 CASE WHEN 吗
不能硬编码——一旦新增状态（比如加了 'cancelled'），SQL 就得手动改。此时 CASE WHEN 本身不支持动态列，但你可以：
- 先查出所有唯一分类值：
SELECT DISTINCT status FROM order_status_log，再拼 SQL（应用层处理） - 接受“最大宽度”设计：预设常用分类（如前5个状态），其余归入
ELSE统计为other_amount - 在报表工具（如 Metabase、Superset）里用透视功能替代 SQL 层转换，SQL 只负责提供干净纵表
强行在纯 SQL 里“自动横表”需要存储过程或递归 CTE（PostgreSQL/SQL Server），复杂度陡增，且无法被大多数 ORM 或 BI 工具识别。
SUM 和 MAX 在横表里到底该选哪个
取决于原始数据语义：
- 要“汇总总量”（如各渠道销售额、各品类销量）→ 用
SUM - 要“取最新/最高/存在性标记”（如用户最后一次登录设备、商品最高评分、是否含优惠券）→ 用
MAX（字符串或数字都可比） - 要“计数”（如各状态出现次数）→ 用
COUNT配合CASE WHEN ... THEN 1 ELSE NULL END（注意别用ELSE 0，否则COUNT(0)也会计数）
性能上没差别，都是单次扫描+分组聚合。但语义错配会导致结果完全失真——比如用 SUM 处理字符串字段会报错，用 MAX 算金额总和会漏掉大部分值。
最易被忽略的是 NULL 处理粒度：每个 CASE WHEN 分支的 ELSE 值类型必须和主表达式一致，否则某些数据库（如 PostgreSQL）会报类型不匹配错误。
