sql server 2022 不支持运行时动态列名，子查询仅能返回值而非标识符；真动态列名必须用 exec + quotename 实现动态 sql，但存在注入、缓存和调试问题；95% 场景只需动态值映射，推荐 join 或带 coalesce 的标量子查询。
SQL Server 2022 不支持运行时拼接列名（比如用 EXEC('SELECT '+ @colname) 以外的方式），所以「动态列名映射」本质上不是真动态——它必须靠子查询 + CASE + 聚合，把不同条件的值“投射”到预定义的列上。硬要绕开这个限制去造“真正动态列名”，只能走动态 SQL，但那就脱离了子查询范畴，且带来注入和执行计划缓存问题。
为什么不能直接用子查询返回列名
子查询是标量或表值表达式，返回的是数据值，不是标识符。SQL Server 解析器在编译阶段就要确定列名和结构，SELECT (SELECT name FROM sys.columns WHERE object_id = ...) 这类写法只会返回字符串值，不会让外层 SELECT 多出一列。试图用它控制列名，结果只有两种：Invalid column name 或语法错误。
用子查询 + CASE 实现“逻辑列映射”
这是最常用、最可控的方式：把原始字段值作为条件，用子查询查出对应映射值，再用 CASE 把它分配到固定列位。关键点在于——映射规则必须可静态表达。
- 映射表必须存在（如
status_map），且字段有索引（如old_code） - 子查询必须是标量子查询（最多返回一行一列），否则报错
Subquery returned more than 1 value - 务必加
IS NULL检查，避免意外NULL覆盖原值，例如：COALESCE((SELECT new_label FROM status_map WHERE old_code = t.status), t.status) - 示例：
SELECT id, (SELECT cat_name FROM category_map WHERE cat_code = t.category) AS category_name, (SELECT dept_fullname FROM dept_lookup WHERE dept_abbr = t.dept) AS dept_fullname FROM orders t
替代方案：用 JOIN 替代子查询更高效
当映射关系稳定、关联字段有索引时，JOIN 比相关子查询快得多，尤其在大表上。SQL Server 优化器对 JOIN 的执行计划更成熟，而相关子查询可能被重复执行每行一次。
- 错误写法（低效）：
(SELECT name FROM mapping WHERE code = t.code)在 10 万行表中可能执行 10 万次 - 推荐写法：
SELECT t.id, m1.cat_name AS category_name, m2.dept_fullname FROM orders t LEFT JOIN category_map m1 ON m1.cat_code = t.category LEFT JOIN dept_lookup m2 ON m2.dept_abbr = t.dept
- 注意：用
LEFT JOIN保证主表行不丢失；若映射缺失需兜底，用ISNULL(m1.cat_name, t.category)
动态列名真需求？只能走 EXEC + QUOTENAME
如果业务真要求“列名随参数变”（比如前端传 @year = '2024'，就要生成 [sales_2024] 列），就必须用动态 SQL。子查询做不到，也没法绕过。
- 必须用
QUOTENAME(@year)防注入，不能直接拼字符串 - 无法参数化列名，
sp_executesql只能参数化值，不能参数化标识符 - 每次执行都生成新执行计划，缓存效率低；调试困难，错误堆栈指向动态字符串内部
- 简单示意：
DECLARE @sql NVARCHAR(MAX) = N'SELECT id, amount AS sales_' + QUOTENAME(@year, '[') + ' FROM sales'; EXEC sp_executesql @sql;
真正容易被忽略的是：所谓“动态列名映射”，95% 的场景其实只需要动态 *值* 映射——用子查询或 JOIN 就够了。强行追求列名动态，往往暴露的是建模问题：该拆成键值对的没拆，该用配置表的硬编码进列名，最后反而让查询变脆弱、难维护、难索引。
