SQL Server 的 PIVOT 必须配合聚合函数（如 MAX），需先整理为三列结构；MySQL/PostgreSQL 无 PIVOT，须用 CASE WHEN + GROUP BY；动态列优先应用层处理，性能差异小，关键在数据过滤与 NULL 处理。
SQL Server 里用 PIVOT 做行转列，必须先聚合
直接套用 PIVOT 却报错 “The PIVOT operator requires a pivot column and an aggregate function”？不是漏写了聚合函数，就是没理解它的强制逻辑：哪怕你只是想“原样转”，也得选一个聚合方式，比如 MAX() 或 MIN()。
常见错误是把明细数据直接丢进 PIVOT 子句，结果 SQL Server 拒绝执行。正确做法是：先用子查询或 CTE 把源数据整理成「分组键 + 展开列 + 值列」三列结构，再在 PIVOT 中指定聚合函数和固定列名列表。
-
PIVOT不支持动态列名，列名必须写死，例如FOR category IN ([A], [B], [C]) - 如果原始数据中某组缺失某个 category 值，对应单元格会是
NULL，不会自动补 0 或空字符串 -
MAX()在单值场景下最安全；若一行可能有多个同 category 的值，要确认业务是否允许取最大值
MySQL / PostgreSQL 没有 PIVOT，用 CASE WHEN + GROUP BY 替代
在 MySQL 8.0+ 或 PostgreSQL 中写 PIVOT 会直接报错 “syntax error at or near 'PIVOT'”。这时候得靠传统组合拳：CASE WHEN 构造各列，再用 GROUP BY 合并同一分组的多行。
关键点在于：每个目标列都要写一个 MAX(CASE WHEN ...)（或其他聚合），不能只写 CASE WHEN —— 否则 GROUP BY 会报错 “nonaggregated column”。
- 示例中若原始表有字段
user_id,metric,value，想按user_id行转列，则SELECT user_id, MAX(CASE WHEN metric = 'score' THEN value END) AS score, ... GROUP BY user_id - PostgreSQL 可用
COALESCE(MAX(...), 0)把 NULL 转为 0，MySQL 同理 - 列数一多，
CASE WHEN块容易写串，建议先生成列名列表再拼 SQL，别手敲 20 个
动态行转列：不要硬写 SQL，优先考虑应用层组装
当列名来自数据表（比如不同产品线、不同问卷题号），且数量不固定时，硬写 PIVOT 或一堆 CASE WHEN 不现实 —— 既难维护，又容易 SQL 注入或语法错误。
更可行的做法是：用普通 SELECT 查出长格式结果（如 user_id, category, value），在 Python/Java/Node.js 里用 pandas.pivot()、Stream.collect(Collectors.groupingBy()) 或 reduce() 组装宽表。数据库只负责提供清晰、无歧义的明细数据。
- 强行在 SQL 里拼动态列，要用存储过程 +
EXEC()（SQL Server）或EXECUTE format()（PostgreSQL），但调试困难、权限要求高、缓存失效快 - 如果必须 SQL 动态化，先确认是否真需要实时生成——很多场景用定时任务预计算宽表更稳
- 注意字符集：动态拼接时，category 值含单引号或反斜杠会破坏 SQL 结构，务必转义或参数化
PIVOT 和 CASE WHEN 的性能差异其实很小，别过早优化
有人担心 CASE WHEN 写太多会影响执行计划，或者 PIVOT 内部有黑盒开销。实测表明：只要基础查询走索引、结果集不大，两者执行时间基本一致；瓶颈通常卡在 JOIN 或 WHERE 条件上，而不是转列逻辑本身。
真正影响性能的是数据量级和分组粒度。比如对千万级用户按月份做行转列，无论哪种写法，都可能触发磁盘排序或内存溢出。
- 加
WHERE过滤后再转列，比全表转列后过滤快得多 - SQL Server 中，
PIVOT的执行计划里会出现Compute Scalar和Concatenation算子，但和等价CASE WHEN的Compute Scalar没本质区别 - 如果列特别多（50+），生成的 SQL 文本可能超客户端缓冲区限制，这时
CASE WHEN更容易拆解调试
实际项目里最常被忽略的，是 NULL 值语义和空字符串的混用——比如业务认为 “没填就是 0”，但数据库存的是 NULL，转列后不显式处理就会变成空单元格，报表一导出就出错。
