不能直接用 join 行转列，需配合 group by 和聚合函数；join 仅用于关联字典表以动态获取列名，如 attr_dict 映射 attr_key 为可读名称，主逻辑仍是 group by + max(case when ...)。
用 JOIN 做行转列？先说结论：不能直接做，得配合 GROUP BY 和聚合函数
单纯靠 JOIN 无法完成行转列（pivot）。它只是关联多表或同一表的多行，但不会把分散的行值“堆”成一列里的多个字段。真正起作用的是 GROUP BY + MAX(CASE WHEN ...) 这类模式——JOIN 只在需要从其他表取维度描述（比如把 category_id 换成 category_name）时才参与进来。
什么时候必须加 JOIN 才能完成行转列？
典型场景：原始数据只有 ID 和键值对（如 user_id, attr_key, attr_value），但你要展示的列名（比如 “姓名”“电话”“地址”）存在另一张字典表里，而不是硬编码在 SQL 中。
- 必须
JOIN字典表，把attr_key = 'phone'映射为可读列名 - 否则你只能写死
CASE WHEN attr_key = 'phone' THEN attr_value END，维护性差 -
JOIN发生在子查询或 CTE 里，主逻辑仍是GROUP BY user_id+ 聚合
示例片段：
SELECT t.user_id, MAX(CASE WHEN d.name = '姓名' THEN t.attr_value END) AS name, MAX(CASE WHEN d.name = '电话' THEN t.attr_value END) AS phone FROM user_attrs t JOIN attr_dict d ON t.attr_key = d.code -- 关键：用 JOIN 把 code 翻译成业务名称 GROUP BY t.user_id;
LEFT JOIN vs INNER JOIN 在行转列中影响什么？
取决于你是否允许缺失属性的记录出现在结果里。这直接影响最终行数和 NULL 值分布。
- 用
INNER JOIN：只要某条attr_key在字典表里不存在，整行被过滤掉 → 行数变少，但每行字段都“有据可查” - 用
LEFT JOIN：即使attr_key没匹配到字典项，原记录仍保留，对应列返回 NULL → 行数不变，但可能混入不可解释的 NULL - 如果字典表不全（比如历史遗留 key 未录入），
LEFT JOIN更安全；如果严格校验数据一致性，INNER JOIN更早暴露问题
为什么别在 ON 条件里写 CASE 或复杂表达式？
有人试图这样写：ON d.code = CASE t.attr_key WHEN 'name' THEN 'NAME_FIELD' ELSE t.attr_key END —— 看似灵活，实则埋雷。
- 数据库优化器很难对带函数的
ON条件生成高效执行计划，尤其当attr_dict很大时，可能放弃走索引 - 语义混乱：把“字段映射逻辑”和“关联逻辑”耦合在一起，后续改一个映射规则就得动整个
JOIN - 正确做法是先用子查询或 CTE 把
attr_key标准化，再干净地JOIN字典表
容易被忽略的一点：行转列真正的复杂度不在 JOIN，而在动态列数——SQL 不支持运行时决定列名。如果业务要求“用户自定义字段”，要么前端拼 SQL（注意注入），要么用应用层收数据后重组，数据库层做不到全自动 pivot。
