优先使用条件聚合而非PIVOT；仅当运行环境为SQL Server、列名动态生成且团队统一规范时才考虑PIVOT；条件聚合需用聚合函数包裹CASE WHEN，注意ELSE默认值、NULL处理及多维拆分；性能瓶颈在于GROUP BY基数、数据倾斜与索引缺失。
优先用条件聚合，除非你用的是 SQL Server 且明确需要动态列名。PIVOT 是 SQL Server 特有的语法糖，可读性差、调试难、不支持嵌套或复杂表达式；条件聚合（CASE WHEN + SUM/COUNT）跨数据库通用、逻辑透明、可控性强。
什么时候必须用 PIVOT
仅当满足以下全部条件时才考虑：
• 运行环境是 SQL Server（或 Azure SQL），其他数据库如 PostgreSQL/MySQL/Oracle 不支持该语法
• 需要从行转列的“列名”是动态生成的（比如按月份自动变成 [2026-01], [2026-02]），且你愿意配合 EXEC() 拼接动态 SQL
• 团队已统一使用 PIVOT 风格，且有配套的元数据管理机制
否则，PIVOT 带来的额外维护成本远高于它省下的几行代码。
CASE WHEN 条件聚合怎么写才不踩坑
常见错误是漏掉 ELSE 0 或误用聚合函数：
- 必须用聚合函数包裹
CASE WHEN，比如SUM(CASE WHEN region = 'CN' THEN sales END)，不能直接写CASE WHEN ... THEN sales -
CASE分支里不要写NULL以外的默认值，否则会影响SUM/AVG计算；统一用ELSE 0（数值）或ELSE ''（字符串） - 如果原始字段本身含
NULL，COUNT(column)会跳过它，但COUNT(*)不会——注意区分语义 - 多个维度交叉时（如
region×product_type），别试图在一个CASE里塞两个条件，应拆成独立字段，或改用GROUP BY多列
性能差异主要卡在 GROUP BY 和数据倾斜上
无论用 PIVOT 还是条件聚合，底层都依赖 GROUP BY。真正拖慢查询的不是语法选择，而是：
-
GROUP BY字段组合基数太高（例如user_id+event_timestamp） - 某类值占比严重失衡（如
status = 'pending'占 95%，导致 reducer 负载不均） - 没给分组字段建索引，或统计字段未做分区裁剪
这时候优化重点应放在预过滤（WHERE）、降基（如把时间戳截断到天）、或加 WHERE status IN ('success', 'failed') 显式排除长尾值。
条件聚合写起来多敲几行，但改起来快、查起来清、换库也不用重写——多数真实场景里，这点“多写”换来的是后续两周不用救火。
