SQL Server的PIVOT不支持变量列名，必须用动态SQL拼接执行；IN子句必须为硬编码静态列表，如([A],[B])，变量@cols直接引用会语法报错；安全拼接需用QUOTENAME()和STRING_AGG()，并以sp_executesql参数化执行。
SQL Server 的 PIVOT 本身不支持变量列名，必须用动态 SQL 拼接执行；硬写死列名的报表在真实业务中基本不可用，动态生成才是落地刚需。
为什么不能直接把变量塞进 IN 子句里
常见错误写法：PIVOT (SUM(Amount) FOR Category IN (@cols))——SQL Server 解析器会在语法检查阶段就报错，提示“必须是常量表达式”。@cols 是变量，不是字面量，引擎根本不会进入执行阶段。
- SQL Server 要求
IN后面的括号内必须是明确、静态的列名列表，比如([North],[South],[East]) - 哪怕你用
EXEC('...')包裹整个SELECT ... PIVOT，只要里面出现@cols这种变量引用，依然会失败 - 真正能跑通的，是把列名拼成字符串后，整个 SQL 语句变成纯文本再交给
sp_executesql执行
怎么安全拼出动态列名（含空格/特殊字符）
列名来自数据（比如 AreaName = '华东分公司' 或 'North America'），直接拼接会破坏语法甚至引发注入。必须用 QUOTENAME() 转义。
-
STRING_AGG(QUOTENAME(Category), ',')是 SQL Server 2017+ 最稳妥的方式，自动加方括号并转义特殊字符 - 低于 2017 版本得用
FOR XML PATH('')，但要手动处理NULL和开头逗号，且漏掉QUOTENAME()会导致Category = ']'直接让 SQL 崩溃 - 务必加
DISTINCT：重复值会让PIVOT报错“列名重复” - 空结果集时
@cols是NULL，后续拼接会产出SELECT ... PIVOT (...) IN ()这种非法语法，需提前IF ISNULL(@cols, '') = '' RAISERROR(...)
为什么必须用 sp_executesql 而不是 EXEC
EXEC 只能传入字符串，无法参数化；而 sp_executesql 支持参数绑定，这对性能和安全都关键。
- 执行计划可复用：相同结构的动态 SQL（仅参数值不同）能共用缓存计划，
EXEC每次都是全新编译 - 避免 SQL 注入：用户输入的
@Year等参数通过参数化传入，不参与字符串拼接 - 示例中
@sql字符串里写WHERE Year = @year_param，然后调用sp_executesql @sql, N'@year_param INT', @year_param = @Year - 别忘了给
@sql声明为NVARCHAR(MAX)，否则超长会被截断
容易被忽略的兼容性与权限细节
动态 PIVOT 在生产环境跑不起来，往往卡在这些地方：
- 存储过程执行者需有源表
SELECT权限，以及对sp_executesql的执行权限（通常默认有） - 若源数据来自视图或函数，确保执行上下文能访问它们；跨库查询需用三段式名
db.schema.table -
STRING_AGG在 SQL Server 2016 及更早版本不可用，强行使用会报错“无法识别的内置函数” - 列名过多（比如上千个地区）可能导致
@sql超过NVARCHAR(MAX)实际限制（约 2GB），此时应考虑前端分页或服务端聚合
动态列生成看着只是字符串拼接，但每一步都踩着 SQL Server 的解析规则和安全边界。最脆弱的点不在逻辑，而在 QUOTENAME() 是否漏掉、@cols 是否为空、参数是否绑定——这些地方出错，整条语句就静默失败或报一堆无关错误。
