UNPIVOT 不能直接作用于 GROUP BY 的最终结果，必须将其包裹在子查询或 CTE 中作为源表；IN 子句需显式列出静态列名，NULL 值默认被过滤，输出的属性列和值列必须在 SELECT 中显式声明别名。
UNPIVOT 不能直接对 GROUP BY 结果做列转行
你写完 GROUP BY，再想直接在它后面加 UNPIVOT——SQL Server 会报错。因为 UNPIVOT 是表运算符，只能作用于「表或子查询结果」，而 GROUP BY 后的 SELECT 是最终投影，不是可被再次运算的中间表。必须把分组逻辑包进子查询或 CTE 里，再对外层结果做 UNPIVOT。
常见错误现象：Incorrect syntax near 'UNPIVOT' 或 The column 'xxx' was specified multiple times for 'unpvt'，往往就是没隔离好作用域。
- 正确做法：用括号包裹分组查询，作为
UNPIVOT的源表 - 别在
SELECT列表里混用聚合列和非聚合列，否则子查询本身就会失败 - 如果分组后字段名含空格或特殊字符，
UNPIVOT的IN子句里必须用方括号包裹，比如[Sales Q1]
UNPIVOT 的 IN 列表必须是静态列名，不能是表达式
UNPIVOT 要求明确列出所有待转换的列，不支持通配符、变量或运行时计算列名。这意味着：如果你的分组结果动态生成了不同数量的季度列（如 Q1, Q2, Q3），但某次查询只返回 Q1 和 Q2，你仍得在 IN (Q1, Q2, Q3) 中写全——缺失列会变成 NULL，不会报错，但容易漏数据。
性能影响：列越多，UNPIVOT 扫描行数呈线性增长；若原始宽表有 100 列要转，UNPIVOT 输出行数会是原行数 × 100，内存和 tempdb 压力明显上升。
- 确认分组后输出的列结构稳定，再硬编码进
IN子句 - 避免在
IN中写ISNULL(Q1, 0)这类表达式——语法不支持，会提示Incorrect syntax near '(' - 列名大小写敏感性取决于数据库排序规则，建议统一小写避免歧义
NULL 值在 UNPIVOT 中默认被过滤掉
这是最容易被忽略的行为：UNPIVOT 默认跳过值为 NULL 的单元格，不会生成对应行。例如分组后某客户 Q3 销售额为 NULL，那这一行就不会出现在 UNPIVOT 结果里——看起来像数据丢失，其实是设计如此。
使用场景：如果你需要保留结构完整性（比如后续要 JOIN 其他维度表），必须提前用 ISNULL() 或 COALESCE() 填充 NULL，否则关联会断裂。
- 推荐填充策略：
ISNULL(Q1, 0) AS Q1，而不是留空或用字符串'N/A'（类型需一致） - 注意填充后类型变化：原
DECIMAL列填0没问题，但填''会隐式转VARCHAR，导致UNPIVOT报类型冲突 - 测试时用
WHERE Q1 IS NULL OR Q2 IS NULL查看原始 NULL 分布，预估过滤影响面
UNPIVOT 后的属性列名和值列名必须显式声明别名
UNPIVOT 语法强制要求两个新列：一个存原列名（如 'Q1'），一个存对应值（如 1200.00）。这两个列名必须在 SELECT 列表中明确写出，不能依赖 AS 在 UNPIVOT 子句里定义——那是无效的。
典型错误：SELECT dept, unpvt.* FROM (...) UNPIVOT (amount FOR quarter IN (Q1,Q2)) AS unpvt，这样 unpvt.* 会报错，因为 UNPIVOT 输出的两列没有被 SELECT 显式引用。
- 正确写法：
SELECT dept, quarter, amount FROM (...) UNPIVOT (amount FOR quarter IN (Q1, Q2)) AS unpvt - 别名不能和源表列重名，否则
SELECT *会引发歧义，尤其在多层嵌套时 - 如果源表已有
quarter列，UNPIVOT的FOR后名字必须不同，比如改用period
实际操作中，最复杂的点不在语法本身，而在确认分组后的列结构是否稳定、NULL 是否可接受、以及如何让 UNPIVOT 输出能被下游逻辑可靠消费——这些都得在写第一行代码前想清楚。
