sql server的unpivot不支持动态列名，必须用动态sql拼接，关键在于安全构造in子句（用quotename+string_agg）、统一数据类型（显式cast）及处理null；替代方案cross apply values更灵活可控。
unpivot 本身不支持动态列名，硬写会报错
SQL Server 的 UNPIVOT 要求列名必须在语句编译时确定，不能用变量代替。直接写 UNPIVOT(... FOR col IN (@cols)) 会触发错误：Incorrect syntax near '@cols'。这不是权限或版本问题，是语法限制 —— SQL Server 不允许在 IN 子句里放变量或表达式。
常见错误现象：
- 把字符串拼成
'[A],[B],[C]'直接塞进IN，结果语法报错 - 试图用 CTE 或视图绕过，但
UNPIVOT的列列表仍需静态 - 在存储过程中用
EXEC(@sql)却忘了处理列名中的特殊字符（如空格、中文、括号）
动态列转行必须用动态 SQL 拼接完整 UNPIVOT 语句
核心思路：先查出要转的列名，拼成合法的 IN 列表，再组装整个 UNPIVOT 查询。关键不是“怎么用 UNPIVOT”，而是“怎么安全拼字符串”。
实操建议：
- 用
sys.columns或INFORMATION_SCHEMA.COLUMNS获取目标列，过滤掉不需要转的（如主键、时间戳） - 列名必须用方括号包裹，防止含空格或关键字：用
QUOTENAME(column_name)，别手写'[' + col + ']' - 拼接
IN子句时，用STRING_AGG(QUOTENAME(column_name), ',')（SQL Server 2017+），老版本用FOR XML PATH - 最终执行前，先用
PRINT @sql看生成的语句是否可读、括号是否匹配
示例片段（简化）：
DECLARE @cols NVARCHAR(MAX) = '';
SELECT @cols = STRING_AGG(QUOTENAME(COLUMN_NAME), ',')
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'sales_data' AND COLUMN_NAME NOT IN ('id', 'date');
<p>DECLARE @sql NVARCHAR(MAX) = N'
SELECT id, attribute, value
FROM sales_data
UNPIVOT (value FOR attribute IN (' + @cols + N')) AS u';</p><p>EXEC sp_executesql @sql;</p>
动态 SQL 中的 NULL 值和数据类型要手动对齐
UNPIVOT 要求所有被转的列必须是相同数据类型，否则运行时报错：The type of column "xxx" conflicts with the type of other columns specified in the UNPIVOT list。动态拼接时没人帮你检查这个。
使用场景中容易忽略的点：
- 数值列混着字符串列（比如
amount是DECIMAL，status是VARCHAR），必须显式CAST或CONVERT统一为NVARCHAR类型 - 源列有
NULL，而UNPIVOT默认跳过NULL行；如果业务需要保留，得先用ISNULL(col, '''')填充（注意空字符串和NULL区别） - 拼接后的动态语句里，
CAST必须写全，不能只写CAST(col AS VARCHAR)—— 缺少长度会导致隐式截断或性能下降
替代方案：不用 UNPIVOT，用 CROSS APPLY VALUES 更灵活
如果只是想把多列“摊开”成行，且列数不多、结构相对固定，CROSS APPLY (VALUES ...) 往往比动态 UNPIVOT 更易读、更可控，也避开了列类型强制统一的坑。
适用条件：
- 列名已知或可枚举（比如固定 5 个指标字段）
- 需要给每列指定别名（如
'revenue','cost'），而不是靠列名自动转 - 想在展开同时做简单计算（如
revenue - cost）
示例（静态写法，无动态 SQL）：
SELECT id, metric, value
FROM sales_data
CROSS APPLY (VALUES
('revenue', CAST(revenue AS SQL_VARIANT)),
('cost', CAST(cost AS SQL_VARIANT)),
('profit', CAST(profit AS SQL_VARIANT))
) AS v(metric, value);
注意：SQL_VARIANT 可暂存不同底层类型，但下游处理时仍需 TRY_CAST 或判断 SQL_VARIANT_PROPERTY。
真正麻烦的从来不是语法怎么写，而是列名从哪来、类型怎么统、NULL 怎么算 —— 这些细节没对齐，动态拼出来的东西跑一次就崩一次。
