直接用CASE WHEN + GROUP BY是最稳的选择，需确保GROUP BY字段能唯一确定每组行，每个目标列配聚合函数并显式写ELSE NULL，避免PIVOT的局限性和动态列风险。
直接用CASE WHEN + GROUP BY是最稳的选择
几乎所有SQL引擎都支持，不用管数据库版本或扩展是否启用。关键不是“能不能写”，而是“GROUP BY字段是否真能唯一确定每组原始行”。比如关联后得到user_id, category, value三列，想按user_id横向展开，就必须GROUP BY user_id——漏掉它，结果就是每行一个category，根本没转成列。
常见错误现象：CASE WHEN category = 'A' THEN value END没套聚合函数，MySQL 5.7+会直接报错ERROR 1055；旧版MySQL则可能返回随机值。
- 每个目标列必须配一个聚合：数值累加用
SUM(CASE WHEN ... THEN value ELSE 0 END)，取唯一值用MAX(CASE WHEN ... THEN value END) -
ELSE NULL要显式写出，别省略——否则某些数据库会把空分支转成0或空字符串，干扰后续判断 - 如果
value字段可能为空字符串，先在子查询里用NULLIF(value, '')清洗，再进CASE WHEN，避免MAX()被空串拉低
PIVOT只适合SQL Server且列名固定
SQL Server的PIVOT本质是语法糖，不解决动态列、多维度或条件过滤问题。它要求IN子句里的列名必须是硬编码字面量，比如IN ([语文], [英语])，不能写IN (SELECT DISTINCT subject FROM scores)，也不能用变量拼接——除非你主动上EXEC()动态SQL。
常见错误现象：Msg 8120报错，通常是因为外层SELECT里漏了GROUP BY字段，或者FOR后面放错了列（比如把值列score放进去，而不是分类列subject）。
-
FOR后面只能跟单个分类字段，不能是表达式（如UPPER(subject)） - 中文列名必须加
N''前缀，否则匹配失败：IN (N'语文', N'英语') - 结果列默认无别名，容易和源表字段冲突，务必用
AS显式命名，比如[语文] AS chinese_score
关联后行转列最容易踩的坑是重复数据
JOIN本身就会放大行数，如果关联前没去重，或关联条件不严谨（比如没加时间范围、没限定最新版本），GROUP BY后的MAX()或SUM()就可能把不该累加的值全吞进去。
典型翻车场景：用户表左连订单表，一个用户有多笔订单，又连了商品表，结果同一user_id+category组合出现十几行——这时MAX(CASE WHEN category='A' THEN price END)只取最大价格，但业务本意可能是“该用户在A类商品上的总花费”。
- 先确认业务语义：是要取最新一条？最高值？还是必须去重后再聚合？
- 复杂逻辑别硬塞进
PIVOT，用子查询预处理更可控，比如SELECT user_id, category, MAX(price) AS price FROM orders GROUP BY user_id, category再进主查询 - 如果关联后行数暴涨，优先检查JOIN条件是否漏了索引字段，而不是急着调
CASE WHEN写法
动态列名必须由应用层处理
数据库内拼IN ('A','B','C')看似可行，实则调试难、权限高、缓存失效快。真正可维护的做法，是让Python用pandas.pivot()、Java用Collectors.groupingBy()、Node.js用reduce()在内存里组装宽表，SQL只负责输出规范的长格式明细（如user_id, category, value）。
强行在SQL里搞动态列，哪怕用QUOTENAME()防注入，也绕不开sp_executesql执行、结果集结构不确定、无法静态校验等问题。一旦列名含特殊字符或长度超128，整个语句就挂。
- 列名来自数据表？先查出合法值到临时表，过滤掉空值、特殊字符、超长项
- 需要排序控制？
STRING_AGG()（SQL Server/PostgreSQL）或GROUP_CONCAT()（MySQL）比PIVOT更灵活，但要注意长度限制 - 别为“看起来一行SQL搞定”牺牲可读性——多数真实场景里，应用层处理比动态SQL更易测试、回滚和监控
CASE WHEN别急着跑，先SELECT *看下关联后原始数据长什么样。 
