SQL Server的PIVOT不支持动态列名，必须用动态SQL拼接：先用STRING_AGG与QUOTENAME安全生成列名列表，再通过sp_executesql执行；需显式分组、指定聚合函数、过滤NULL，并注意权限与注入防护。
SQL Server 存储过程中用 PIVOT 前必须写死列名
SQL Server 的 PIVOT 不支持子查询或变量直接填入 IN 子句，比如 IN (SELECT DISTINCT Category FROM Sales) 会报错 Incorrect syntax near 'SELECT'。你只能写成 IN ([Electronics], [Books], [Clothing]) 这种硬编码形式。
这意味着：如果业务要求“自动包含所有新增品类”，就不能在存储过程里只写一条静态 PIVOT 查询——必须拼接 SQL 字符串再执行。
- 先用
STRING_AGG(QUOTENAME(Category), ',')从维度表中生成列名列表（注意QUOTENAME防注入） - 把结果赋给
@cols变量，再拼进完整@sql字符串里 - 最后用
EXEC sp_executesql @sql执行，不能用EXEC(@sql)（后者不支持参数化）
PIVOT 要求源数据是三列结构，且聚合函数不可省略
源子查询必须明确提供三个角色字段：分组键（如 user_id）、类别列（如 subject）、值列（如 score）。少一个就会报错 The PIVOT operator requires a value for the column being pivoted。
即使每个分组键+类别组合都唯一（比如主键 ID + 科目），也得写 MAX(score) 或 MIN(score)，不能省略聚合函数。否则提示 Incorrect syntax near 'FOR'。
- 类别列值必须是合法标识符，含空格或特殊字符要靠
QUOTENAME包裹，否则执行时报错Invalid column name - 若某分组键缺失某个类别的值（如张三没考英语），对应列就是
NULL，不会自动补 0；需要外层用ISNULL([English], 0)处理
动态列场景下，PIVOT 和 CASE WHEN 性能差异不大，但调试难度差很多
万级到十万级数据下，拼接字符串执行 PIVOT 和手写几十个 CASE WHEN 的执行时间基本一致。真正拉开差距的是可维护性：
-
PIVOT动态版：出错时错误信息指向EXEC行，实际问题可能在@cols拼接逻辑里，查起来绕三圈 -
CASE WHEN静态版：SQL 直接报错在哪一行哪一列，改完立刻重试 - 权限上，
sp_executesql需要EXECUTE权限，而普通SELECT不需要；上线前容易漏掉授权检查
如果你的品类数长期稳定在 10 个以内（比如固定 6 个产品线），优先手写 CASE WHEN；只有当品类每月新增、且 DBA 明确放行动态 SQL 权限时，才走 PIVOT 拼接路线。
MySQL / PostgreSQL 存储过程根本不能用 PIVOT 语法
直接执行 SELECT ... PIVOT (...) 会报错：ERROR: syntax error at or near "PIVOT"（PostgreSQL）或 You have an error in your SQL syntax（MySQL）。这两个数据库压根没有 PIVOT 关键字。
替代方案只有两种：
- 用
CASE WHEN + 聚合手动展开，每新增一个类别就得加一段MAX(CASE WHEN category = 'X' THEN amount END) AS X - PostgreSQL ≥9.4 可用更简洁的
FILTER语法：SUM(amount) FILTER (WHERE category = 'Electronics')，语义清晰但版本兼容性要卡死
别指望在跨库存储过程中抽象出统一的 “pivot 接口”——不同方言的底层能力断层太明显，硬套只会让代码变成条件编译地狱。
