PIVOT必须配合SUM、COUNT等聚合函数使用，本质是先分组再聚合后展开，不可省略；IN子句列名须用方括号包裹；输出为独立派生表，过滤和排序需置于整个语句末尾。
PIVOT 在 SQL Server 中不是万能的“透视表生成器”，它必须配合聚合函数使用，且仅适用于已知列值的静态场景。如果你试图直接 PIVOT 而不写 SUM、COUNT 或 AVG，查询会报错 —— 因为 PIVOT 本质是“先分组再聚合再展开”，不是简单地把行变列。
为什么必须用聚合函数？
PIVOT 的设计逻辑决定了它无法保留原始行数：当多行共享同一个非透视列（如 Region = 'North'）但对应不同透视列值（如 Product = 'Apple' 和 'Banana'）时，SQL Server 必须把它们“压进一行”。这时就需要明确告诉数据库：“同一组里多个 Amount 值，你要怎么合并？”——SUM、MAX、COUNT 就是这个指令。
- 漏写聚合函数会触发错误：
Incorrect syntax near the keyword 'FOR' - 即使源数据中每个
(Region, Product)组只有一条记录，也必须显式指定聚合函数；MIN或MAX在这种情况下等价于“取值”，但语法上不可省略 - 聚合发生在
PIVOT子句内部，外部不能再对透视列做GROUP BY—— 否则会提示Invalid column name，因为透视列在逻辑上属于PIVOT输出的派生表
IN 子句里的列名必须用方括号包裹
PIVOT 的 IN 列表不是变量或表达式，而是字面量列标识符。如果列值含空格、特殊字符或匹配关键字（如 Order、User），不加 [ ] 会直接报错。
- 正确：
IN ([Apple], [Banana], [Orange Juice]) - 错误：
IN (Apple, Banana, Orange Juice)→ 报错Incorrect syntax near 'Juice' - 动态构建时也要确保
QUOTENAME()包裹，否则遇到Product = 'O''Reilly'这类带单引号的数据会引发 SQL 注入或语法中断
常见误用：把 PIVOT 当成 SELECT 别名来嵌套
很多人试图在 PIVOT 外层再套一层 SELECT * 并加 WHERE，结果发现过滤失效或列找不到。这是因为 PIVOT 输出的是一个**独立的派生表**，它的列名只在该子句作用域内有效。
- 错误写法：
SELECT * FROM (...) PIVOT (...) WHERE [Apple] > 100→ 报错Invalid column name 'Apple' - 正确做法：把
WHERE放到最外层SELECT，或在PIVOT的源子查询中提前过滤（如SELECT Region, Product, Amount FROM Sales WHERE Amount > 0） - 排序也同理：
ORDER BY必须放在整个PIVOT语句末尾，不能塞进源子查询里
性能和兼容性关键点
PIVOT 是语法糖，底层仍走常规聚合执行计划。但它对索引不敏感，且无法利用并行度优化 —— 特别当 IN 列表很长（比如上百个动态产品）时，执行计划可能退化为嵌套循环 + 多次扫描。
- 数据库兼容级别必须 ≥ 90（即 SQL Server 2005+），低于此值会报错
Incorrect syntax near 'PIVOT' - 没有
PIVOT等价的统计信息，SQL Server 无法准确预估中间结果集大小，容易选错连接算法 - 若需高频、低延迟透视，优先考虑预计算视图或物化结果表，而非每次实时
PIVOT
真正难的从来不是写出能跑的 PIVOT，而是判断什么时候不该用它——比如列值不确定、需要支持前端自由拖拽维度、或目标数据库其实是 PostgreSQL/MySQL，这时候硬套 PIVOT 语法只会卡在第一步。
