JOIN 无法实现行转列，因其仅能横向拼接而不能分组内结构化聚合；应使用 GROUP BY 配合 ROW_NUMBER() 和 CASE WHEN + MAX() 实现动态列提取。
为什么不能直接用 JOIN 做行转列
JOIN 本身是横向拼接表的工具，它按关联字段把多行数据“拉平”成更宽的行，但无法把同一组内的多行值（比如一个用户有 3 条订单记录）自动聚合成单行里的多个列（如 order_1_id、order_2_id、order_3_id）。强行用 JOIN 模拟会导致笛卡尔爆炸、NULL 堆积、逻辑脆弱——尤其当每组行数不固定时，根本没法预设 LEFT JOIN 次数。
真正需要的是“分组内结构化聚合”，而这不是 JOIN 的职责。
用 GROUP BY + 条件聚合替代 JOIN
核心思路：放弃为每条源行建一列，改用 CASE WHEN 配合聚合函数，在每个分组内“挑出”特定条件的值，再用 MAX() 或 MIN() 消除 NULL 干扰。
典型场景：把用户订单按时间顺序转为前 3 笔订单字段
-
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at)先给每组内的行编号 - 用子查询或 CTE 把编号暴露为普通列（否则不能在
GROUP BY后直接引用窗口函数结果） - 主查询按
user_id分组，对编号 = 1/2/3 的行分别用MAX(CASE WHEN rn = 1 THEN order_id END)提取 - 注意：必须用
MAX或MIN，因为CASE在每组里只有一行命中，其余为 NULL，聚合后剩那个非 NULL 值
WITH ranked AS (
SELECT user_id, order_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at) AS rn
FROM orders
)
SELECT
user_id,
MAX(CASE WHEN rn = 1 THEN order_id END) AS first_order_id,
MAX(CASE WHEN rn = 1 THEN amount END) AS first_order_amount,
MAX(CASE WHEN rn = 2 THEN order_id END) AS second_order_id,
MAX(CASE WHEN rn = 3 THEN order_id END) AS third_order_id
FROM ranked
WHERE rn <= 3
GROUP BY user_id;
不同数据库对动态列的支持差异
上面写死 rn = 1/2/3 是最通用做法，但如果你真需要“自动适配最多 N 列”，就得依赖数据库特性：
- PostgreSQL：可用
crosstab()（需启用tablefunc扩展），但输入必须严格两列+分类列，且列名需提前声明 - SQL Server：支持
PIVOT语法，但列名必须硬编码或用动态 SQL 拼接 - MySQL 8.0+：没有原生
PIVOT，GROUP_CONCAT可横向拼字符串，但不算真正“列” - ClickHouse / DuckDB：部分支持
groupArray+ 数组下标访问，接近但仍是数组而非独立列
也就是说：纯标准 SQL 里没有“自动行转列”语法，所有“优雅”都建立在明确知道最大列数、且能接受静态定义的基础上。
容易被忽略的 NULL 和排序陷阱
行转列结果里大量 NULL 不是 bug，而是数据不齐的自然体现。但如果你发现该有值却全是 NULL，大概率栽在这几个点上：
- 窗口函数的
ORDER BY表达式未覆盖全部排序歧义（比如时间相同、ID 未参与排序），导致rn分配不稳定 WHERE rn 写在聚合前（正确），如果误写在 <code>GROUP BY后，会过滤掉整个分组- 关联字段类型不一致（如
user_id一边是INT一边是VARCHAR），隐式转换失败，JOIN或PARTITION BY失效 - 聚合时没处理空值：比如用
SUM(amount)没问题，但若想取首个非 NULLamount，得用MAX(CASE ...)而不是COALESCE，后者在分组里不生效
真正难的从来不是写出第一版，而是当业务要求从“前 3 单”变成“最近 3 笔有效订单（status IN ('paid', 'shipped')）”时，能否快速把过滤条件塞进 CTE 而不破坏整个结构。
