PIVOT适用于列名固定且数量少的行转列场景，更简洁；CASE WHEN则在列名动态、需预处理或复杂逻辑时更可控，且跨数据库兼容。
什么时候该用 PIVOT 而不是一堆 CASE WHEN
当源数据中「行转列的键值对」结构清晰、列名固定且数量不多（比如 3–10 个），PIVOT 更简洁；但一旦列名来自动态数据（如用户自定义标签）、或需要做类型转换/聚合前过滤，CASE WHEN 实际更可控。SQL Server 的 PIVOT 本质是语法糖，底层仍走聚合，不支持 NULL 值直接透传，也强制要求聚合函数（哪怕只是 MAX()）。
常见错误现象：Msg 8120, Level 16 —— 忘了在 SELECT 列表里把非聚合列都放进 GROUP BY，或者没意识到 PIVOT 后的列名必须严格匹配 IN 子句里的字面值（大小写敏感、空格敏感）。
-
PIVOT的IN列表只接受字面量，不能写变量或子查询 - 若原始数据某组内同一
FOR列对应多个值，MAX()会静默丢数据——得先用ROW_NUMBER()预处理去重 -
PIVOT结果列默认无别名，容易和源表字段名冲突，务必用AS显式命名
CASE WHEN 实现行转列时怎么避免 NULL 干扰聚合
用 CASE WHEN 的核心是：每个目标列单独构造一个条件表达式，再套一层聚合（通常是 MAX() 或 SUM()）。关键点不在“写几个 WHEN”，而在于聚合粒度是否对齐——必须确保 GROUP BY 的字段能唯一确定每组原始行的归属。
典型翻车场景：源表有 id, attr_name, attr_value，想按 id 横向展开。如果漏掉 GROUP BY id，或者误把 attr_name 也放进 GROUP BY，结果会变成一行一属性，完全达不到“一 id 一行”的目的。
- 每个
CASE WHEN分支末尾加ELSE NULL（显式而非省略），避免意外隐式转换 - 若
attr_value是数值型但含空字符串，先用NULLIF(attr_value, '')清洗，否则MAX()可能返回空串而非真实最大值 - 不要在
CASE WHEN内部做复杂计算（如CONVERT+ISNULL嵌套），先在子查询里处理好类型，再进CASE
动态列名必须用动态 SQL，但怎么防注入又保可读性
当列名来自表数据（例如 SELECT DISTINCT category FROM products），硬编码 IN (N'手机', N'电脑') 不现实，只能拼接 SQL 字符串。这时候重点不是“会不会拼”，而是“拼完能不能安全执行+方便调试”。
错误做法：直接把用户输入拼进 @sql 变量；正确做法：用 QUOTENAME() 包裹每一个动态列名，并用 sys.dm_exec_describe_first_result_set 验证最终语句结构（开发期可用）。
- 拼接前先查出所有合法列名到临时表，排除含特殊字符、长度超 128 的项
-
EXEC sp_executesql @sql, N'@param INT', @param = 123—— 即使动态部分全是列名，参数化仍要保留，便于后续加条件参数 - 调试时把生成的
@sql打印出来（PRINT @sql），复制到新窗口手动执行，比盲目EXEC容易定位语法错误
性能差异在哪？什么情况下 PIVOT 反而更慢
表面看 PIVOT 是内置操作，应该更快，但实际执行计划常显示它多了一层 Compute Scalar 和额外的 Hash Match。当源数据量大（>100 万行）、且 FOR 列高基数（比如时间戳、GUID），PIVOT 的哈希构建开销可能超过 CASE WHEN + GROUP BY 的流式聚合。
另一个隐形成本：如果目标列中有大量 NULL，PIVOT 仍会为每组分配内存槽位；而 CASE WHEN 在优化器看来更“透明”，更容易被简化或跳过空分支。
- 测试时用
SET STATISTICS IO, TIME ON对比逻辑读和 CPU 时间，别只看执行时间 -
PIVOT无法利用FOR列上的非聚集索引进行 Seek，而CASE WHEN的GROUP BY若覆盖索引完整，可能走 Index Scan + Stream Aggregate - 如果后续还要对转列结果
JOIN其他大表，CASE WHEN子查询更容易被优化器“下推”条件，PIVOT常被当作独立派生表固化
最麻烦的其实是维护：动态列逻辑一旦上线，下次加个新分类，既要改数据表，又要改存储过程里的字符串拼接逻辑，还不能漏掉 QUOTENAME() —— 这种耦合比看起来更脆弱。
