PIVOT 不支持动态列名，必须用 STRING_AGG + QUOTENAME 动态拼接 SQL 字符串后通过 sp_executesql 执行；内层子查询仅筛选关联，聚合应在 PIVOT 中或外层进行。
PIVOT 本身不支持动态列名，必须先拼接 SQL 字符串
SQL Server 的 PIVOT 运算符要求列名在编译时就确定，无法直接用变量或子查询生成列名。你看到的“动态列”效果，本质是动态拼接 T-SQL 字符串再执行（EXEC 或 sp_executesql），不是 PIVOT 自身能力。
常见错误现象：Incorrect syntax near '@cols' 或 Invalid column name '@cols'——这是试图把变量直接写进 PIVOT 子句里导致的。
- 必须用子查询（如
SELECT STRING_AGG(...)）先查出所有目标列值（如不同年份、产品类别） - 把这些值拼成逗号分隔字符串（如
'[2021],[2022],[2023]'），赋给@cols变量 - 再把
@cols注入到完整 SQL 字符串中，用sp_executesql执行（比EXEC更安全，支持参数化）
子查询生成列名时，STRING_AGG 需配合 QUOTENAME 防注入和非法标识符
从数据表中提取列名候选（比如 SELECT DISTINCT category FROM sales），不能直接拼进 SQL——category 值含空格、连字符、中文或保留字（如 order）会报错。
正确做法是用 QUOTENAME() 包裹每个值，再用 STRING_AGG() 合并：
SELECT @cols = STRING_AGG(QUOTENAME(category), ',') FROM (SELECT DISTINCT category FROM sales) AS tmp
这样 category = 'Sales Order' 会变成 [Sales Order]，category = 'order' 变成 [order]，避免语法错误和 SQL 注入风险。
- SQL Server 2017+ 才有
STRING_AGG；低版本需用FOR XML PATH('')替代 -
QUOTENAME默认用方括号，也可传第二个参数指定（如QUOTENAME(col, '''')用于单引号包裹字符串字面量） - 若列名来源不可信（如用户输入），跳过
QUOTENAME就等于开放 SQL 注入入口
嵌套子查询位置决定性能与语义：聚合必须在外层完成
想按地区统计各产品的销售额并转为列（产品为列名），容易把 SUM(amount) 放在内层子查询里——这会导致逻辑错误：PIVOT 期望的是「行转列前」的原子值，不是已聚合的结果。
正确结构是：
- 内层子查询只做基础筛选和关联（如
SELECT region, product, amount FROM sales JOIN products...），不聚合 - 外层
PIVOT对这个结果集做SUM(amount) FOR product IN (...) - 或者把聚合放在 PIVOT 之后（如外层再套
SELECT region, [A], [B] FROM (...) AS pvt GROUP BY region），但通常冗余
性能影响明显：内层提前 GROUP BY 会减少 PIVOT 输入行数，但可能丢失明细粒度；没聚合则 PIVOT 内部会重复计算，大数据量时慢且内存占用高。
替代方案：条件聚合（CASE + MAX/SUM）更可控，适合简单动态场景
如果只是按固定维度（如年份、状态）转列，且列数不多（CASE WHEN 比动态 SQL 更轻量、可读性更高，也绕过权限和缓存问题。
例如：
SELECT region, SUM(CASE WHEN year = 2021 THEN amount END) AS [2021], SUM(CASE WHEN year = 2022 THEN amount END) AS [2022] FROM sales GROUP BY region
它天然支持“动态”列逻辑（只要你知道有哪些年份），无需拼 SQL、无注入风险、执行计划稳定。只有当列集合完全未知（如每日新增品类）才必须上动态 PIVOT。
真正难的不是写出动态 SQL，而是判断什么时候不该用它——多数业务报表的“动态列”其实都是有限、可枚举的，硬上 PIVOT 反而增加维护成本和出错概率。
