PIVOT必须嵌套在带别名的子查询中，强制三段结构：内层SELECT加别名、中间PIVOT加别名、外层引用pvt；必须指定聚合函数，不支持明细行直接旋转；动态列需拼SQL或改用CASE WHEN+GROUP BY。
PIVOT 必须套在子查询里，否则语法直接报错
SQL Server 的 PIVOT 不是独立语句，它只能作为表源的一部分参与查询；漏掉最内层带别名的子查询，比如写成 SELECT * FROM Sales PIVOT (...)，就会触发 Msg 156, Level 15, State 1: Incorrect syntax near the keyword 'PIVOT'。
正确结构强制三段嵌套：
- 最内层：任意合法 SELECT，必须加表别名，如
(SELECT Region, Product, Amount FROM Sales) AS src - 中间层：
PIVOT (SUM(Amount) FOR Region IN ([North], [South])) AS pvt，整个 PIVOT 子句也必须有别名 - 最外层：对
pvt别名做SELECT *或具体字段引用
少一个 AS、漏一对括号、或把 IN 里的值写成 (North, South)（没方括号），都会中断解析。
聚合函数不是可选项，而是 PIVOT 的刚性前提
PIVOT 本质是“先聚合、再旋转”，它不处理原始明细行。哪怕你只想把字符串拼起来，也不能直接写 PIVOT (Name FOR Category IN (...)) —— 这会报错。
必须显式指定聚合逻辑：
- 数值汇总：用
SUM、AVG、COUNT - 字符串拼接：SQL Server 2017+ 可用
STRING_AGG，但得先包在子查询里预聚合，再喂给PIVOT - 取最新一条：无法单靠
PIVOT实现，得先用ROW_NUMBER() OVER (PARTITION BY ... ORDER BY Date DESC)在子查询中标记，再用CASE WHEN rn = 1 THEN Value END配合外部MAX模拟
常见误操作：把明细字段直接塞进 PIVOT 的聚合位置，例如 PIVOT (ProductName FOR Region IN (...)) —— 缺聚合函数，SQL Server 拒绝执行。
动态列值场景下，硬写 PIVOT 反而增加维护成本
当要透视的列值不确定（比如年份每年新增、产品类别随业务变化），PIVOT 的 IN 列表不支持变量或子查询，只能拼 SQL 字符串后 EXEC。
这时候手写 PIVOT 很容易踩坑：
- 拼接出的列名若含空格或关键字，必须手动加方括号，比如
[2025 Sales]，漏了就语法错误 - 拼接逻辑要过滤掉 NULL 或非法字符，否则生成的 SQL 运行时报错
- 权限问题：动态执行需要
EXECUTE权限，生产环境常被限制
更稳妥的做法是放弃 PIVOT，改用 CASE WHEN ... THEN ... END + GROUP BY。它天然支持运行时判断，且语句结构清晰、调试方便，跨 SQL Server 版本（包括 2005）和跨数据库（MySQL/PostgreSQL）也基本兼容。
多维度聚合时，PIVOT 的表达力明显受限
如果需求是“每个产品下，既要显示各区域销售额总和，又要显示各区域最新一笔订单日期”，PIVOT 无法在一个子句中同时输出两个不同聚合逻辑的结果。
因为 PIVOT 只允许一个聚合函数，且所有列共享同一组 IN 值。
此时必须拆解：
- 方案一：用两个独立
PIVOT分别处理金额和日期，再JOIN—— 冗余、易错、性能差 - 方案二：在子查询里先用窗口函数计算每组的
MAX(OrderDate)和对应订单 ID，再用CASE分别提取值 —— 更直接，也更容易加条件（比如只取状态为 ‘Shipped’ 的记录）
真正复杂的透视逻辑，往往不是语法能不能写出来的问题，而是后续改需求时，PIVOT 嵌套越来越深、括号越套越多，最后连自己都看不懂——这种时候，回到 CASE + GROUP BY 反而是最省心的选择。
