优先使用条件聚合而非pivot，因其跨数据库兼容、逻辑清晰、支持动态列和边界处理；pivot仅在sql server 2005+/oracle 11g+、列名长期固定、业务接受丢行或报错时才适用。
优先用条件聚合，除非你明确只跑 SQL Server 或 Oracle 且列值完全固定。 PIVOT 看似简洁，但硬编码、不兼容、难调试，实际落地时反而拖慢迭代节奏。
PIVOT 只在三个条件同时满足时才值得用
它不是“更高级”，只是特定场景下的语法糖。真要用，得确认：
- 数据库是 SQL Server 2005+ 或 Oracle 11g+，且项目锁定不迁移
- 要转的列名（如
[status]、[priority]）长期不变，新增字段需人工改 SQL - 业务方接受“缺失某 key 就整行丢弃”或“类型不一致直接报错”，而不是填
NULL
只要其中一条不成立，PIVOT 就从捷径变成隐患。比如在 SQL Server 中写 FOR type IN (@cols)，会直接报错 Incorrect syntax near '@cols' —— 变量不能进 IN 列表，这是语法铁律。
条件聚合（CASE WHEN + 聚合）才是跨库通用解
它不依赖数据库特性，逻辑直白，还能自然处理边界情况：
- 某组数据没有
product = 'Keyboard'？SUM(CASE WHEN product = 'Keyboard' THEN amount ELSE 0 END)算出来就是 0，不会丢行 - 想过滤再聚合？
WHERE sale_date >= '2026-01-01'直接加在子查询外层，PIVOT 却必须先 GROUP BY 再透视，没法提前剪枝 - MySQL / PostgreSQL / Spark SQL 全支持，连 SQLite 都能跑
示例：统计每月各产品销售额，MySQL 和 SQL Server 都能用同一套写法：
SELECT sale_month, SUM(CASE WHEN product = 'Laptop' THEN amount ELSE 0 END) AS Laptop, SUM(CASE WHEN product = 'Mouse' THEN amount ELSE 0 END) AS Mouse FROM ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS sale_month, product, amount FROM sales ) t GROUP BY sale_month;
动态列需求下，PIVOT 完全失效
报表系统常要“自动列出所有产品”，这时 PIVOT 没法用。有人试图拼接 SQL 字符串再 EXEC(@sql)，但这就已脱离纯 SQL 范畴，进入应用层逻辑。而条件聚合配合程序生成列部分，更可控：
- 先查出所有产品：
SELECT DISTINCT product FROM products - 程序拼出 N 个
SUM(CASE WHEN product = 'X' THEN ...)片段 - 注入主查询，执行——整个过程可加日志、可缓存、可 fallback
硬写 PIVOT 动态列，等于把元数据管理责任甩给 DBA，而实际开发中，产品线增减比表结构变更还频繁。
最易被忽略的一点：PIVOT 的执行计划里隐含多个 Compute Scalar 步骤，列一多，CPU 时间明显上涨；而条件聚合就是标准聚合路径，优化器熟得很。别为少敲几行代码，换掉可预测的性能。
