SQL 列转行(Unpivot)的几种实现方式

13次阅读

sql列转行(Unpivot)是将宽表转为长表的操作,主流实现方式有四种:1.原生UNPIVOT(SQL Server/oracle),语义清晰但要求同类型且过滤NULL;2.union ALL模拟,通用但冗长;3.jsON函数动态展开,灵活适配动态列;4.CROSS JOIN+VALUES,兼顾可读性与效率。

SQL 列转行(Unpivot)的几种实现方式

SQL 中的列转行(Unpivot)操作,本质是将宽表结构(多列代表不同属性)转换为长表结构(属性名和值分两列存储),常用于数据标准化、报表汇总或对接分析工具。不同数据库UNPIVOT 的原生支持程度不同,实现方式也略有差异。

使用原生 UNPIVOT(SQL Server、Oracle)

SQL Server 和 Oracle 提供了标准的 UNPIVOT 语法,语义清晰、性能较好,适合明确列名且数量固定的场景。

以 SQL Server 为例:

select id, attribute, value FROM (   SELECT id, name, age, city   FROM users ) AS src UNPIVOT (   value FOR attribute IN (name, age, city) ) AS unpvt;

注意点:

  • 所有被 unpivot 的列必须是相同数据类型,否则需提前用 CASTCONVERT 统一;
  • IN 子句中列出的列名不能带别名,也不能是表达式;
  • 结果中会自动过滤掉 NULL 值(除非源数据允许并需要保留)。

用 UNION ALL 模拟(通用兼容方案)

mysqlpostgresqlsqlite 等不支持原生 UNPIVOT 的数据库,常用 UNION ALL 多次查询拼接实现等效效果,灵活性高,但写法略冗长。

示例(MySQL/PostgreSQL):

SELECT id, 'name' AS attribute, name AS value FROM users UNION ALL SELECT id, 'age', CAST(age AS VARCHAR) UNION ALL SELECT id, 'city', city ORDER BY id, attribute;

关键细节:

  • 每条 SELECT 必须有相同数量和顺序的列,类型需兼容(建议显式转换);
  • 字符串字面量(如 'name')作为属性名,便于后续分组或筛选;
  • 若原始列含 NULLUNION ALL 会保留,无需额外处理。

json 函数动态展开(PostgreSQL、MySQL 8.0+)

现代数据库支持 JSON 操作后,可先将行转为 JSON 对象,再用函数展开键值对,适合列名不固定或需动态处理的场景。

PostgreSQL 示例:

SELECT    id,   j.key AS attribute,   j.value AS value FROM users, LATERAL json_each_text(   to_jsonb(users) - 'id' ) AS j;

说明:

  • to_jsonb(users) 将整行转为 JSONB;- 'id' 排除主键;
  • json_each_text() 展开为键值对key 是列名,value 是字符串值;
  • 所有值统一为文本类型,如需保持原类型,需配合 CASE 或自定义函数转换。

用 CROSS JOIN + VALUES(SQL Server、PostgreSQL)

利用行构造器(VALUES)配合 CROSS JOIN,逻辑简洁,可读性优于 UNION ALL,且支持计算列。

SQL Server 示例:

SELECT    u.id,   v.attribute,   CASE v.attribute     WHEN 'name' THEN u.name     WHEN 'age'  THEN CAST(u.age AS VARCHAR)     WHEN 'city' THEN u.city   END AS value FROM users u CROSS JOIN (VALUES ('name'), ('age'), ('city')) AS v(attribute);

优势:

  • 只需遍历一次原表,比多次 UNION ALL 更高效(尤其大数据量);
  • VALUES 可扩展为带权重或条件的元数据表,便于配置化管理;
  • CASE 表达式灵活支持类型转换和业务逻辑。

选择哪种方式,取决于目标数据库版本、列是否动态、性能要求以及维护成本。原生 UNPIVOT 最规范,UNION ALL 最通用,JSON 方案最灵活,CROSS JOIN + VALUES 则在可读性与效率间取得较好平衡。

text=ZqhQzanResources