sql server不支持动态列名，必须用动态sql（sp_executesql）配合quotename安全拼接；替代方案包括应用层处理或for json返回键值对。
SQL Server不支持动态列名的SELECT语句
直接在 SELECT 中用变量拼出列名（比如 SELECT @col_name FROM table）会报错 Must declare the scalar variable "@col_name" 或更常见的 Invalid column name —— 因为列名在编译期就必须确定，不能运行时解析。
这不是语法写错了，是引擎设计限制：T-SQL 的元数据绑定发生在查询编译阶段，列名属于结构定义，不是表达式求值范畴。
- 所有尝试用
CONCAT、QUOTENAME拼接列别名并直接SELECT的写法，都会失败 -
PIVOT/UNPIVOT本身也不接受变量列名，只能硬编码 - 视图、内联表值函数、CTE 同样无法绕过这个限制
唯一可行路径：动态SQL + EXEC 或 sp_executesql
必须把整个 SELECT 语句构造成字符串，再执行。关键不是“怎么拼”，而是“怎么安全拼”和“怎么传参”。
用 EXEC(@sql) 最简，但无法参数化输入值；涉及用户输入或过滤条件时，必须改用 sp_executesql 防注入。
- 列名要用
QUOTENAME(@col_name)包裹，避免 SQL 注入或非法标识符（如含空格、中文、横线） - 如果动态列来自表数据（例如从
sys.columns查出字段名），记得加WHERE is_computed = 0 AND is_hidden = 0过滤掉不可选列 - 结果集结构无法被静态工具识别（SSMS 列提示、EF Core 映射、Power BI 自动推断都会失效）
DECLARE @col_name NVARCHAR(128) = N'OrderDate'; DECLARE @sql NVARCHAR(MAX) = N'SELECT ' + QUOTENAME(@col_name) + N' AS DynamicCol FROM Sales.Orders'; EXEC sp_executesql @sql;
动态列名常用于报表场景，但需接受副作用
典型需求如：按用户选择的维度（Region / ProductCategory）生成不同列头的汇总表。这时本质是“动态报表”，不是“动态查询”。
这类逻辑放在应用层（C#、Python）往往更可控：先查出原始数据，再用代码重组织列结构；数据库只负责提供稳定、可预测的宽表或键值对格式。
- 若坚持在 SQL 层实现，每次列名变更都会导致执行计划缓存失效，高频调用时可能引发
plan cache bloat - 无法用
SELECT INTO #temp直接接收动态结果 —— 临时表结构必须提前定义，或改用表变量 +INSERT EXEC（但后者不支持嵌套EXEC） - 输出列类型由实际值决定，可能因数据变化导致隐式转换错误（比如某次
@col_name指向INT列，下次指向DATETIME）
替代方案：用JSON或通用结构规避列名硬编码
SQL Server 2016+ 支持 FOR JSON，能把任意行转成键值对字符串，列名自然变成 JSON key：
SELECT
OrderID,
JSON_OBJECT('key', ColumnName, 'value', ColumnValue) AS dynamic_pair
FROM (
SELECT OrderID, N'OrderDate' AS ColumnName, OrderDate AS ColumnValue FROM Sales.Orders
UNION ALL
SELECT OrderID, N'Status', Status FROM Sales.Orders
) t;
虽然没真“动态列”，但把列名下推到数据层，应用层解析 JSON 即可自由映射字段。这种方式避免了动态 SQL 的全部风险，且能复用执行计划。
真正麻烦的从来不是“怎么让列名变”，而是“变了之后下游怎么消费”。多数时候，花半小时改应用代码，比在存储过程中调试 QUOTENAME 嵌套和引号逃逸更省事。
