case when行转列本质是分组聚合+条件计数/求值，需配合group by、聚合函数（如max）和else null，适用于离散值转固定字段；动态或多列场景应交由应用层或bi工具处理。
SQL里用CASE WHEN做行转列，本质是分组聚合+条件计数/求值
不是所有“转列”都要写一堆CASE WHEN，只有当你需要把某列的离散值（比如status、product_type）变成多个字段，且原始数据是“一行为一条记录”的时候，才适合这条路。它不生成新表，只是在SELECT里重组织显示逻辑。
常见错误现象：GROUP BY漏了非聚合字段，导致报错ERROR: column "xxx" must appear in the GROUP BY clause；或者CASE WHEN没配ELSE NULL，结果全是0或''，误以为数据丢了。
- 必须搭配
GROUP BY——按你想保留的“行维度”字段分组，比如user_id、month - 每个目标列写一个
CASE WHEN，里面判断源字段是否等于某个值，再取对应要展示的字段（如amount） - 外层必须套聚合函数，最常用
MAX()或SUM()：因为同一组内，只有匹配的那一行有值，其余为NULL，MAX()能安全捞出那个非空值 - 别忘了
ELSE NULL——不写的话，不匹配的行会默认返回0（数值型）或空字符串（字符型），造成数据污染
MySQL和PostgreSQL里CASE WHEN写法一致，但NULL处理细节不同
语法层面，CASE WHEN condition THEN value END在主流SQL方言里完全通用。真正影响结果的是聚合时对NULL的容忍度和默认行为。
使用场景：你导出报表给业务看，要把用户每月的订单类型拆成“电商订单”“线下核销”“退款单”三列，原始表是orders(user_id, order_type, amount, created_at)。
- MySQL 8.0+ 和 PostgreSQL 都支持标准写法，无需额外函数
- PostgreSQL 对
NULL更严格，MAX(NULL)明确返回NULL；老版本MySQL有时会把MAX()作用于全NULL列返回0，得加NULLIF(MAX(...), 0)兜底 - 如果某类数据可能为空（比如某用户当月没下退款单），别指望
CASE WHEN自动补0——它只负责“选”，不负责“填”，补零得靠COALESCE(MAX(...), 0)
性能陷阱：别在大表上无索引地GROUP BY + CASE WHEN
这个操作本身不慢，慢的是背后的GROUP BY。如果分组字段（比如user_id）没有索引，数据库就得全表扫描+临时文件排序，100万行以上就明显卡顿。
常见错误现象：查询执行时间从毫秒级跳到几十秒，EXPLAIN显示Using temporary; Using filesort。
- 先确认
GROUP BY字段有索引，尤其是复合索引要考虑顺序，比如INDEX (user_id, order_type)比单列user_id更优 - 避免在
CASE WHEN里调用函数，比如CASE WHEN YEAR(created_at) = 2024 THEN amount END——这会让索引失效 - 如果只是偶尔查，没问题；如果是高频报表接口，考虑物化结果到汇总表，而不是每次实时算
替代方案：什么情况下不该硬刚CASE WHEN
当你要转的“列”是动态的（比如产品类目每天新增）、或者数量超过10个、或者需要做复杂计算（如同比、占比），CASE WHEN就从工具变成负担了。
使用场景：BI看板需要按销售地区展开全部省份，而省名存在另一张维表里，且经常变动。
- 硬写20个
CASE WHEN维护成本高，容易漏改，SQL也臃肿 - 这时候该交给应用层（Python/Pandas）或BI工具（Tableau/Superset）做透视，SQL只提供宽表基础数据
- PostgreSQL 可用
crosstab()函数，但要求输入结果集严格两列+排序，实际约束多，不如直接换思路 - MySQL 没原生pivot函数，强行用
GROUP_CONCAT拼JSON再解析，得不偿失
真正的难点从来不在怎么写那几行CASE WHEN，而在于想清楚：这个“列”是不是真的该在SQL层固定住？还是它本该是前端可配置的维度？
