如何用SQL实现分组后行转列展示，用PIVOT或CASE语句？

本文共计1151个文字，预计阅读时间需要5分钟。

在大多数实际场景中，`CASE`语句比`PIVOT`语句更可靠、更易于调试、兼容性更好。由于`PIVOT`是SQL Server的专用语法，在PostgreSQL、MySQL、SQLite中基本不存在，因此直接在SQL Server中使用。在SQL Server中，使用`PIVOT`时需要确保硬编码列名、不支持动态值、聚合逻辑有限，否则可能会遇到错误，如Incorrect syntax near 'PIVOT'或列名无效。

用CASE配合GROUP BY是跨数据库通用解法，且能自然融入现有查询结构。

• CASE写法清晰对应“每个分组内，把某条件的值取出来汇总”，逻辑直觉匹配业务需求
• 不需要提前知道所有分类值（比如产品类型有几十种），可用子查询先查出DISTINCT再拼接——而PIVOT必须显式列出每一列
• 可混合不同聚合方式：同一行里SUM(CASE WHEN type='A' THEN amount END)和COUNT(CASE WHEN status='done' THEN 1 END)可以共存

用CASE实现分组+行转列的固定写法

核心结构是：SELECT 分组字段, 聚合函数(CASE WHEN 条件 THEN 字段 END) AS 列名 FROM 表 GROUP BY 分组字段。关键不是“怎么写对”，而是“哪里容易错”。

• 漏掉ELSE NULL会导致非匹配行被算作0（尤其用SUM时），正确写法是SUM(CASE WHEN type='A' THEN sales ELSE 0 END)或更安全的SUM(CASE WHEN type='A' THEN sales END)（让NULL参与聚合，SUM会自动忽略）
• 分组字段必须和GROUP BY完全一致，包括别名不能混用；例如SELECT dept_id AS dept, ... GROUP BY dept会报错，必须写成GROUP BY dept_id
• 如果原始数据有重复行且需去重，不能只靠CASE，得在外层或子查询里先DISTINCT，否则聚合结果会翻倍

示例：按部门统计各产品线销售额

SELECT dept_name, SUM(CASE WHEN product_line = 'Hardware' THEN revenue END) AS hardware_rev, SUM(CASE WHEN product_line = 'Software' THEN revenue END) AS software_rev, COUNT(CASE WHEN status = 'active' THEN 1 END) AS active_count FROM sales GROUP BY dept_name;

PIVOT只在SQL Server特定场景下值得考虑

仅当满足全部条件时才用PIVOT：目标库确定是SQL Server、分类值固定且极少变动、团队熟悉其语法、且查询不涉及多层嵌套或复杂过滤。

• PIVOT必须搭配聚合函数（SUM/AVG/COUNT），不能直接“取值”，所以原始数据里同一分组+同一分类若有多行，必须明确聚合意图
• 列名必须是字面量，不能来自字段或变量；想根据SELECT DISTINCT category FROM config动态生成列？做不到，得拼SQL字符串再EXEC
• 一旦PIVOT后的列在源数据中不存在（比如某部门没有Hardware订单），该列值为NULL，但不会自动补0——常被误认为“数据丢了”

典型写法（SQL Server）：

SELECT dept_name, [Hardware], [Software] FROM ( SELECT dept_name, product_line, revenue FROM sales ) AS src PIVOT ( SUM(revenue) FOR product_line IN ([Hardware], [Software]) ) AS pvt;

性能和可维护性陷阱

两种写法在小数据量下差异不大，但数据量上千万后，CASE通常更快——因为执行计划更简单，优化器容易推导；PIVOT可能触发额外排序或哈希操作。

• 别在CASE分支里写子查询（如CASE WHEN x THEN (SELECT y FROM t2 WHERE t2.id=t1.ref) END），这会让整行变慢；应提前用JOIN拉平数据
• 列太多时（比如50个分类），CASE语句会很长，但可读性反而比PIVOT高；编辑其中一列逻辑，不用担心影响其他列的括号匹配
• 如果前端需要真正动态列（列名/数量每次请求都不同），SQL层不该硬扛，应该在应用层做GROUP BY后遍历组装，避免SQL拼接带来的注入风险和缓存失效

最常被忽略的一点：行转列本质是展示需求，不是存储需求。如果频繁需要这种视图，建个物化视图或定时汇总表比每次实时计算更实际。