PIVOT 不支持变量列名，必须用动态 SQL 拼接执行；需通过 DISTINCT 获取列值、QUOTENAME 转义、STRING_AGG 拼接生成安全列名字符串，并用 sp_executesql 参数化执行防注入与提升性能。
PIVOT 不接受变量列名，必须用动态 SQL 拼接后执行。硬编码列名的静态 PIVOT 无法应对“每月新增产品”“实时标签变化”这类场景——你得自己构造 SQL 字符串并安全执行。
为什么不能直接用 @cols 变量写进 PIVOT 的 IN 子句
SQL Server 解析 PIVOT 时要求 IN 后面是**字面量列表**，比如 ([A],[B],[C])。写成 (@cols) 会直接报错：Incorrect syntax near '@cols'。这不是权限或版本问题，是语法解析阶段就拒绝变量参与。
常见错误写法：
SELECT * FROM (...) AS src PIVOT (SUM(Amount) FOR Category IN (@cols)) AS pvt -- ❌ 报错
根本原因：T-SQL 的语句结构在编译期就固定，IN 子句不支持运行时求值。
怎么安全拼出 [Col1],[Col2] 这种格式的列名字符串
关键三步：查 DISTINCT 值 → 用 QUOTENAME() 转义 → 用聚合函数拼接。漏掉任一环都可能崩：
-
QUOTENAME()必须加：它自动包裹方括号，并转义]、空格、连字符等非法字符（如值为North America→[North America]；值为Item]→[Item]]） - 必须去重：
DISTINCT缺失会导致重复列名，PIVOT直接报错The column 'X' was specified multiple times - 空结果要拦截：若子查询没返回任何行，
@cols为NULL，后续SET @sql = N'SELECT ' + @cols + '...'会得到NULL，执行失败
推荐写法（SQL Server 2017+）：
SELECT @cols = STRING_AGG(QUOTENAME(Category), ',') FROM (SELECT DISTINCT Category FROM Sales WHERE Category IS NOT NULL) AS T;
兼容旧版可改用 FOR XML PATH('')，但需手动处理 NULL 和排序（STRING_AGG 不支持 ORDER BY 子句，旧法反而更灵活）。
为什么要用 sp_executesql 而不是 EXEC
二者都能执行动态 SQL，但差异致命：
-
EXEC(@sql)：每次执行都生成新执行计划，缓存污染；无法参数化，易被注入（尤其当列名来自用户输入或未清洗字段） -
sp_executesql：支持参数化传入（如@Year），复用执行计划；且能显式声明参数类型，避免隐式转换导致索引失效
正确调用示例：
SET @sql = N'
SELECT * FROM (
SELECT Product, Category, Amount
FROM Sales
WHERE Year = @year_param
) AS src
PIVOT (SUM(Amount) FOR Category IN (' + @cols + N')) AS pvt;';
<p>EXEC sp_executesql @sql, N'@year_param INT', @year_param = @Year;注意：@cols 是拼进字符串的，但业务参数（如 @Year）必须走参数化通道——这是防注入和性能的关键分界线。
容易被忽略的边界情况
动态 PIVOT 看似模板化，但上线后常因这些点翻车：
- 列名含 Unicode 或控制字符：
QUOTENAME()默认只处理 ASCII 特殊字符，遇到 emoji 或零宽空格仍可能失败，建议前置清洗 - 列数超限制：SQL Server 单行最多 8,060 字节，若动态列太多（如 200+ 个标签），拼出的
@sql可能截断，需提前LEN(@sql)校验 - 权限不足：执行
sp_executesql需要EXECUTE权限，且源表查询权限不能靠EXECUTE AS绕过——存储过程内权限链要理清 - 执行计划缓存爆炸：不同列组合产生不同
@sql字符串，每种都会缓存独立计划，高频变动列名时考虑加OPTION (RECOMPILE)
最隐蔽的问题是：列名顺序不固定。如果报表依赖“Q1,Q2,Q3”顺序，但 DISTINCT 查询没加 ORDER BY，每次执行列序可能不同——别指望 SQL Server 默认按字母排。
