UNPIVOT的IN子句必须硬编码列名，不支持变量；动态需求须用QUOTENAME()拼接字符串+sp_executesql执行动态SQL，或改用UNION ALL替代以更好控制类型、NULL和过滤逻辑。
UNPIVOT 不能直接用变量写 IN 列表
SQL Server 的 UNPIVOT 运算符要求 IN 子句里的列名必须是**硬编码的标识符**，不接受变量、字符串拼接或子查询结果。哪怕你声明了 @cols NVARCHAR(MAX) 并赋值为 'col1,col2,col3'，直接写 IN (@cols) 会报错：Incorrect syntax near '@cols'。
这是因为 UNPIVOT 解析阶段就需确定列结构，属于“编译时绑定”，不是运行时求值。
- 错误示范：
UNPIVOT (val FOR attr IN (@cols))→ 语法错误 - 正确前提：所有要 unpivot 的列名必须在写 SQL 时明确写出
- 动态需求只能靠生成并执行动态 SQL 实现，无法绕过
用动态 SQL 拼接 UNPIVOT（SQL Server 存储过程标准做法）
核心思路是：先查出目标列名 → 拼成合法的 IN (c1,c2,c3) 字符串 → 构造完整 UNPIVOT 查询 → 用 sp_executesql 执行。
关键注意点：
- 必须用
QUOTENAME()包裹每个列名，防止注入或特殊字符（如空格、中划线）导致语法错误 -
IN列表里所有列必须同类型，拼接前建议统一CAST或CONVERT，比如全转成VARCHAR(500) - 如果源表含 NULL 且需保留，得在子查询里提前用
ISNULL(col, '')处理，因为UNPIVOT默认丢弃 NULL 行
示例片段（存储过程中）：
DECLARE @sql NVARCHAR(MAX), @cols NVARCHAR(MAX);
SELECT @cols = STRING_AGG(QUOTENAME(COLUMN_NAME), ', ')
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'your_table' AND COLUMN_NAME IN ('name', 'age', 'city'); -- 或按业务逻辑筛选
<p>SET @sql = N'
SELECT id, attr, val
FROM (
SELECT id,
ISNULL(CAST(name AS VARCHAR(500)), '''') AS name,
ISNULL(CAST(age AS VARCHAR(500)), '''') AS age,
ISNULL(CAST(city AS VARCHAR(500)), '''') AS city
FROM your_table
) AS src
UNPIVOT (val FOR attr IN (' + @cols + N')) AS u;';</p><p>EXEC sp_executesql @sql;为什么不用 OPENROWSET 或临时表绕过？
有人想用 OPENROWSET 把列名查出来再 join，或建临时表存列定义——这些都解决不了根本问题：UNPIVOT 的 IN 列表仍需静态文本。临时表或变量只是中间载体，最终还得拼字符串 + EXEC。
真正要警惕的是副作用：
- 动态 SQL 无法被缓存重用执行计划（除非参数化彻底且结构稳定）
- 每次执行都触发解析+编译，大表上可能比等价的
UNION ALL更慢 - 权限需显式授予调用者对目标表的
SELECT权限，sp_executesql不自动继承上下文
替代方案：UNION ALL 更可控，尤其字段多或类型杂时
当列名动态、类型不一、或需精细控制每列转换逻辑（比如 age 要转文字描述，city 要映射区域），硬拼 UNPIVOT 反而更麻烦。此时 UNION ALL 虽啰嗦，但每支路可独立处理：
- 各列可单独
CAST/CASE，无需强求类型一致 - NULL 值默认保留，不用额外包裹
ISNULL - 容易加
WHERE过滤某列非空才展开，UNPIVOT做不到这点 - SQL Server 查询优化器对简单
UNION ALL的执行计划更稳定
复杂度高的动态场景，别迷信 UNPIVOT 语法糖——它省的是键盘敲击，不是设计成本。
