GROUP BY 不能直接行转列，必须配合CASE WHEN与聚合函数（如MAX）实现；漏写GROUP BY、分组字段不全或CASE条件不匹配均会导致NULL结果。
为什么直接用 MAX + CASE 做行转列会返回 NULL？
因为 CASE 表达式在每行独立计算，而 MAX() 是聚合函数，必须配合 GROUP BY 才能将多行“折叠”成一行。如果漏写 GROUP BY，或分组字段没覆盖所有非聚合列，结果要么报错（如 PostgreSQL），要么每组只有一行导致 MAX() 无效（看起来像没转成功）。
典型错误写法：SELECT MAX(CASE WHEN type='A' THEN value END) FROM t; —— 缺少 GROUP BY，且没说明按什么维度“转列”（比如按 id 或 user_id）。
- 必须明确“行转列”的主键字段（如
user_id），它将成为GROUP BY的依据 -
CASE中的条件要互斥且完备（避免多个分支同时命中，或全部不命中导致全为NULL） - 所有非聚合字段（如
user_id、name）都得出现在GROUP BY列表里
MySQL 和 PostgreSQL 中 MAX+CASE 行转列的写法差异
核心逻辑一致，但细节处理不同：MySQL 允许 SELECT 中出现未在 GROUP BY 中的非聚合字段（依赖 sql_mode），PostgreSQL 则严格要求一一对应。
以用户订单类型汇总为例（表 orders 含 user_id, order_type, amount）：
SELECT user_id, MAX(CASE WHEN order_type = 'food' THEN amount END) AS food_total, MAX(CASE WHEN order_type = 'clothes' THEN amount END) AS clothes_total, MAX(CASE WHEN order_type = 'electronics' THEN amount END) AS elec_total FROM orders GROUP BY user_id;
- MySQL 8.0+ 默认开启
ONLY_FULL_GROUP_BY，行为与 PostgreSQL 一致；若关闭，SELECT name却不在GROUP BY中会返回任意一行的name，不可靠 - PostgreSQL 要求
SELECT中所有非聚合字段必须显式出现在GROUP BY，例如加name就得写GROUP BY user_id, name -
MAX()在这里本质是“取非空值”，因每个user_id下某order_type最多出现一次；若可能重复，应改用SUM()或AVG()
遇到 NULL 值太多怎么办？COALESCE 和 ELSE 要一起用
MAX(CASE ...) 对不满足条件的行返回 NULL，最终列全是 NULL 很常见——不是语法错，是数据没匹配上。
- 先确认原始数据中
order_type的实际值：SELECT DISTINCT order_type FROM orders;，常发现大小写、空格、拼写差异（如'Food'vs'food'） - 用
ELSE 0显式兜底：MAX(CASE WHEN order_type = 'food' THEN amount ELSE 0 END)，避免整列被NULL拉垮 - 更稳妥是套一层
COALESCE(MAX(...), 0)，因为MAX()本身对空集返回NULL，ELSE只作用于单行CASE分支 - 注意：用
0还是NULL取决于业务——统计类字段补0合理，状态类字段（如is_vip）补NULL更准确
性能瓶颈在哪？别让 MAX+CASE 扫全表
当 orders 表超百万行，GROUP BY user_id 配合多个 CASE 仍可能慢——问题不在写法，而在缺少支撑索引。
- 最佳索引是复合索引：
CREATE INDEX idx_user_type_amt ON orders (user_id, order_type, amount); - 仅
(order_type)索引无效，因为GROUP BY主体是user_id，优化器无法跳过排序 - 如果
order_type值很多（如上百种），CASE分支过多会导致 SQL 维护困难，此时应考虑应用层拼装，或用PIVOT（SQL Server/Oracle）等专用语法 - 临时表预聚合：对高频查询，可建物化视图或定时刷新的汇总表，避免每次实时计算
真正卡住的往往不是 MAX 或 CASE 本身，而是没意识到 GROUP BY 需要索引支持，以及原始数据质量（空值、脏值）比语法更影响结果可信度。
