如何在未知列名的前提下实现任意两张数据表的纵向合并

通用优先方案：JSON列+动态虚拟列（适配90%以上现代数据库） #

这是最贴合该场景的低开发量方案，兼容MySQL 5.7+、PostgreSQL、ClickHouse、SQL Server 2016+等主流数据库，不需要提前预知任何列名，完全支持随时新增键的需求。

• 主表仅需初始化两个固定列：
  • row_id：主键，自增或UUID生成
  • data：JSON类型列，直接存储解析器返回的完整映射键值对，无额外处理
• 无需提前创建任何业务列：所有采集到的新键直接序列化进data列即可，不管是首次出现的键还是批量同键的数据，都直接插入，不需要等待结构梳理
• 高频键按需转独立列：当分析师需要常用某个键（比如示例中的x/y/z）做查询、计算时，执行一次轻量DDL生成对应虚拟列即可，没有的键自动填充NULL，示例对应的列添加语句（以PostgreSQL为例）：

  -- 给x键生成数值型虚拟列
  ALTER TABLE main_data ADD COLUMN x NUMERIC GENERATED ALWAYS AS (data ->> 'x') STORED;
  -- 给y键生成数值型虚拟列
  ALTER TABLE main_data ADD COLUMN y NUMERIC GENERATED ALWAYS AS (data ->> 'y') STORED;
  -- 给z键生成数值型虚拟列
  ALTER TABLE main_data ADD COLUMN z NUMERIC GENERATED ALWAYS AS (data ->> 'z') STORED;
  

• 效果完全匹配预期：执行上述DDL后查询主表，结果和给出的合并表完全一致，不需要任何多表UNION操作，所有数据都在单表存储。
• 批量场景适配：确定接下来N条映射同键的场景，直接批量序列化进data列插入即可，不需要构建临时表再合并，性能比传统拼列方案高30%以上。

老旧数据库适配方案：元数据驱动的动态DDL #

如果使用不支持JSON类型的传统老旧数据库，走元数据维护的动态列路线，同样不需要提前预知列名：

• 额外创建一张元数据表column_metadata，记录主表所有已存在的列信息：

  字段名	类型	说明
  column_name	VARCHAR(64) 主键	映射的键名
  column_type	VARCHAR(32)	对应数据库类型

• 主表初始仅创建row_id主键列，后续每次插入数据时执行如下逻辑：
  1. 遍历当前行映射的所有键，和column_metadata里的已有列做比对
  2. 对新出现的键，先执行ALTER TABLE main_data ADD COLUMN [新键名] [匹配类型]，再把键信息插入column_metadata
  3. 自动拼INSERT语句：已有键填对应值，主表中存在但当前行没有的键自动填NULL
• 批量场景适配：先校验本批次所有键是否都存在，缺的批量补DDL，再批量拼INSERT语句插入主表，不需要临时表中转。

注意：所有拼接入SQL的列名必须做合法性校验（比如过滤特殊字符、做白名单校验），禁止直接把解析器返回的键名直接拼入SQL，防止注入风险。

时序场景专属方案：时序数据库原生支持 #

如果你的采集数据是带时间戳的时序类型，直接选用InfluxDB、TimescaleDB、ClickHouse时序表这类原生支持动态键的数据库，不需要自己维护元数据或JSON列，直接插入键值对即可，查询时自动对缺失的键填充NULL，天然适配单表存储需求。

避坑提醒：不要使用传统动态拼UNION语句的方案，这种方案每次查询都要遍历所有已有列，性能极差，且和单表存储的需求相悖；也不要将数据拆成多表存储，会增加分析师的查询成本。

内容的提问来源于stack exchange，提问作者lambdakappatheta