PIVOT本质是“先聚合、再旋转”，必须配合SUM/COUNT/MAX等聚合函数使用，不接受原始明细行；常见错误包括漏聚合函数、FOR列名未加方括号、IN值未用方括号包裹、嵌套结构括号或别名缺失；动态列、多值关联、兼容性需求下，CASE+GROUP BY更灵活可靠。
SQL Server里用PIVOT前必须先搞懂聚合逻辑
直接套PIVOT却得不到想要的行转列结果？大概率是没意识到它本质是个“先聚合、再旋转”的操作。SQL Server的PIVOT不接受原始明细行，必须配合SUM、COUNT、MAX等聚合函数使用——哪怕你只是想把字符串拼起来，也得先用STRING_AGG（2017+）或子查询预处理。
常见错误现象：Msg 156, Level 15, State 1: Incorrect syntax near the keyword 'PIVOT'，往往是因为漏写了聚合函数，或者FOR列名没加方括号（尤其含空格或关键字时）。
- 聚合列必须明确指定，比如
SUM(SalesAmount)，不能只写SalesAmount -
FOR后面的列名要和源数据中实际值严格一致（区分大小写取决于数据库排序规则） - 如果要透视的列值不确定（如动态年份），
PIVOT本身不支持，得拼接SQL字符串执行
手写PIVOT语法时最容易错的三处括号和别名
PIVOT的嵌套结构容易让人晕：外层是普通查询，中间是PIVOT子句，内层还得套个源子查询。少一个括号、漏一个别名，就报错。
正确结构要点：
- 最内层必须是带别名的子查询，例如
(SELECT Region, Product, Amount FROM Sales) AS src -
PIVOT子句本身要起别名，比如AS pvt，否则外部SELECT *会找不到字段 -
IN列表里的值必须用方括号包裹，即使没空格，例如IN ([North], [South], [East])，写成(North, South)直接报错
示例片段：
SELECT * FROM ( SELECT Region, Product, Amount FROM Sales ) AS src PIVOT ( SUM(Amount) FOR Region IN ([North], [South], [East]) ) AS pvt;
不用PIVOT也能实现行转列：CASE + GROUP BY更灵活
当透视列值不固定、或需要条件过滤（比如只取最新一条记录）、或跨版本兼容（SQL Server 2005以下），硬套PIVOT反而绕路。此时用CASE配合GROUP BY更可控。
优势场景：
- 动态列值：用
STRING_AGG拼出CASE语句再EXEC，比动态PIVOT易读 - 多值聚合：同一分组下需同时取
MAX(Date)和对应Value，PIVOT做不到，但CASE WHEN Date = MAX(Date) THEN Value END可以 - 兼容性：MySQL/PostgreSQL没有
PIVOT，但CASE写法通用
简写示意：
SELECT Product, SUM(CASE WHEN Region = 'North' THEN Amount END) AS North, SUM(CASE WHEN Region = 'South' THEN Amount END) AS South FROM Sales GROUP BY Product;
性能差异：大数据量下PIVOT和CASE谁更快？
实测在千万级表上，两者执行计划几乎一致——最终都走哈希匹配或流聚合，瓶颈在扫描和分组，不在语法形式。真正影响性能的是是否对FOR列或GROUP BY列建了索引。
注意点：
-
PIVOT隐式强制分组，无法跳过GROUP BY逻辑，所以没索引时一样慢 - 若
IN列表过大（比如几百个值），PIVOT生成的执行计划可能膨胀，而CASE语句长度可控 - 调试困难：出错时
PIVOT报错信息模糊，不如CASE逐段注释排查直观
复杂点在于：业务逻辑一旦涉及“每个用户最近3次订单的金额分别作为列”，就必须放弃PIVOT，改用窗口函数预处理+CASE，这点容易被忽略。
