数据版本控制从表级到库级：OceanBase seekdb的Fork能力扩展

OceanBase数据库官方博客

234人浏览 · 2026-06-23 16:03:28

OceanBase数据库官方博客 · 2026-06-23 16:03:28 发布

Agent 写完一段业务逻辑，跑出来的结果表有 500 行。预期表也有 500 行。哪些行对了、哪些值错了、多了还是少了？

你打开 SQL 编辑器，开始写 LEFT JOIN + CASE WHEN + UNION ALL……写完发现漏了 NULL 的情况，改。改完发现排序不对，再改。折腾半小时，终于拿到差异，复制粘贴给 Agent，让它改代码。Agent 改完，你再跑一遍这套 SQL……

代码有 git diff，一行命令。数据呢？

DIFF TABLE actual_result AGAINST expected_result;

这是 seekdb 1.2.0 引入的 SQL 原语。

Agent 写代码，用它验证输出是否符合预期；Agent 改数据，用它审核改了哪些行、值对不对，再决定要不要合回主表。思路和 Git 一样——Fork 建分支，DIFF 看差异，MERGE 合回去。

立即试用 OceanBase 企业版，体验国产数据库能力

180 天免费试用，零门槛开通

你正在经历这些痛点吗？

Agent 参与开发后暴露出的问题，以及多分支开发、多团队协作、实验回收，本质上都是同一个问题：数据变更缺少像代码一样的分支、对比和合并能力。

如果以上有一条戳中你，接着往下看。

seekdb 的做法：先 Fork 出副本，让 Agent 在副本上执行；再用 DIFF 看清差异；确认无误后，用 MERGE 按策略合回。把数据层也变成像 Git 一样可分支、可比对、可合并。

seekdb 1.2.0 带来了三个新的 SQL 原语——Fork Database、DIFF TABLE、MERGE TABLE——在数据库内核层面补齐了数据版本控制的完整闭环。配合此前已有的 Fork Table 能力，seekdb 构建起了从单表分支到整库克隆、从差异对比到策略合并的完整数据版本控制体系。

先看一个最贴近 coding agent 的例子：

-- 基线库：输入表 + 结果模板表
CREATE TABLE test.orders_input (id INT PRIMARY KEY, amount DECIMAL(10,2), status VARCHAR(20));
INSERT INTO test.orders_input VALUES(1, 100, 'pending'), (2, 200, 'pending');
CREATE TABLE test.result_template (id INT PRIMARY KEY, final_amount DECIMAL(10,2));
-- 每次测试先 Fork 一份隔离环境
FORK DATABASE test TO test_run;
-- Agent 写的业务逻辑跑出来的实际结果
FORK TABLE test_run.result_template TO test_run.actual_result;
INSERT INTO test_run.actual_result
SELECT id, CASE WHEN amount >= 150 THEN amount * 0.9 ELSE amount END
FROM test_run.orders_input;
-- 人工或规则系统给出的预期结果
FORK TABLE test_run.result_template TO test_run.expected_result;
INSERT INTO test_run.expected_result VALUES(1, 100), (2, 180);
-- 对比实际结果和预期结果
DIFF TABLE test_run.actual_result AGAINST test_run.expected_result;

DIFF 没有输出，说明 Agent 写的逻辑符合预期；有输出，差异精确到具体行和具体值，可以直接反馈给 Agent 继续修改。同样的思路也适用于 Agent 改数据：先在 Fork 出的副本上执行修改，用 DIFF 审核改动，确认后 MERGE … STRATEGY THEIRS 合回主表。

下面逐一介绍 Fork Database、DIFF TABLE、MERGE TABLE 三个原语的设计、语法和实战用法。

Fork Database：从单表分支到整库克隆

回顾 Fork Table

seekdb 1.1.0 引入了 Fork Table，通过写时复制（Copy-on-Write）和快照隔离，实现了毫秒级的单表数据分支。一条 FORK TABLE t1 TO t1_fork;，即可在一致性快照点上创建一个逻辑独立、完全可读写的表副本，源表和分支表互不干扰。

关于 Fork Table 的技术原理和使用方式，我们此前已有专文详细介绍，这里不再展开。

Fork Table 解决了单表沙箱问题。但真实业务往往不止一张表。

Fork Database 解决什么新问题

假设你有一个业务库 prod，里面有 orders、users、payments 三张表，它们之间通过外键关联。你想基于当前生产数据创建一个隔离的实验环境。

如果逐表 Fork，每张表的快照时刻可能不同——orders Fork 时 payments 还没写入最新一笔，导致实验库中订单和支付记录对不上。外键约束也无法跨表保持。

Fork Database 正是为了解决这个问题。它在指定时间点（系统自动选取的快照时刻）为源数据库创建一个完整的目标数据库副本，所有用户表共享同一快照版本。

核心特性

库级原子快照：目标库内所有表共享同一 fork 快照版本，多表关联查询、外键约束在 fork 后保持逻辑一致

数据库属性继承：目标库继承源库的字符集（charset）、排序规则（collation）等数据库级属性
库内外键完整保留：源库中表间外键关系（仅限库内引用）在目标库中完整保留并生效；跨库外键在 fork 时被跳过，不在目标库中创建
支持多次 fork：支持对同一源库多次 fork 到不同目标库，每次 fork 使用各自快照时刻，各目标库相互独立

语法与示例

FORK DATABASE source_database TO destination_database;

一个最小可执行的流程：

-- 创建库副本
FORK DATABASE db_src TO db_fork;
-- 目标库可查询
USE db_fork;
SELECT count(*) FROM t1;
-- 目标库可写入（写入不会影响源库 db_src）
INSERT INTO t1 VALUES(...);

也可以用于整库分支与版本管理：

-- 1) 基于主版本创建分支版本（数据基线为 fork 时刻快照）
FORK DATABASE db_prod TO db_prod_branch_v2;
-- 2) 在分支库上进行实验性变更
-- ... 对 db_prod_branch_v2 中的表执行 DML/业务流程 ...
-- 3a) 快速回滚：停止使用分支版本
DROP DATABASE db_prod_branch_v2;

Fork 之后可以放心地改。但改了哪些行？值对不对？能不能合回主表？

没有 Diff & Merge，这些问题只能靠手写 JOIN 和对比 SQL 来回答

DIFF TABLE 与 MERGE TABLE：看清改了什么，安全合回去

Fork 出副本 → 在副本上改 → DIFF 看清差异 → MERGE 按策略合回。和 Git 的 branch、diff、merge 一一对应。

先看一个最小、可直接执行的例子：

CREATE TABLE demo.student_base (id INT PRIMARY KEY, name VARCHAR(20), score INT);
INSERT INTO demo.student_base VALUES(1, 'Alice', 80), (2, 'Bob', 90), (3, 'Charlie', 70);
FORK TABLE demo.student_base TO demo.t_current;
FORK TABLE demo.student_base TO demo.t_incoming;
UPDATE demo.t_incoming SET score = 85 WHERE id = 1;
DELETE FROM demo.t_incoming WHERE id = 2;
INSERT INTO demo.t_incoming VALUES(4, 'David', 95);
-- 先看差异
DIFF TABLE demo.t_incoming AGAINST demo.t_current;
-- 再决定是否合并；这里用 THEIRS 表示冲突时采用 incoming 版本
MERGE TABLE demo.t_incoming INTO demo.t_current STRATEGY THEIRS;
-- 合并后查看结果
SELECT * FROM demo.t_current ORDER BY id;

这个例子里会发生什么？

id=1：两边都有，但 score 不同，属于冲突行
id=2：只在 t_current 里有，属于 current 独有
id=3：两边完全相同，不会出现在 DIFF 结果里
id=4：只在 t_incoming 里有，属于 incoming 独有

预期 DIFF 输出：

__table      __flag  id  name     score
t_current    INSERT   1  Alice    80
t_incoming   INSERT   1  Alice    85
t_current    INSERT   2  Bob      90
t_incoming   INSERT   4  David    95

执行 MERGE … STRATEGY THEIRS 后，t_current 预期变成：

id  name     score
1   Alice    85
2   Bob      90
3   Charlie  70
4   David    95

DIFF TABLE

DIFF TABLE incoming_db.incoming_t AGAINST current_db.current_t;

行为：

语句顺序：固定为 incoming 在前、current 在后；这和结果集中同一主键下的展示顺序是两件事
只读：不修改任何表，仅输出差异结果集
对比规则：按主键逐行对比 current 与 incoming。主键相同、非主键列值不同视为冲突，两表各输出一行；主键仅在一表存在视为独有；主键和值都相同则不输出
结果排序：按主键排序，同一主键下 current 行排在前面
NULL 比较：使用 <=> 运算符，NULL 与 NULL 视为相等
前置条件：两表列定义需完全一致（列名、类型、顺序），且均有主键

MERGE TABLE

MERGE TABLE incoming_db.incoming_t INTO current_db.current_t
  STRATEGY {FAIL | THEIRS | OURS};

行为：

目标：将 incoming 的变更合并到 current 表，会修改 current 的数据
事务：在单个事务中执行，失败则自动回滚（包括 FAIL 策略检测到冲突时）
非冲突行（所有策略一致）：incoming 有而 current 无的行，插入到 current；current 有而 incoming 无的行，保留不动。MERGE 不删除任何行
冲突行（主键相同、值不同）：按所选策略处理——FAIL 报错回滚，THEIRS 用 incoming 覆盖，OURS 保留 current 不动

限制：暂不支持 schema 不同的表。DIFF 和 MERGE 要求两表列定义完全一致（列名、类型、顺序），否则会报错。

典型应用场景

开篇展示了 Agent 写代码和 Agent 改数据两个场景。实际上，Fork + DIFF + MERGE 的组合能覆盖更多数据工作流。下面逐一展开。

场景 1：AI Agent 写代码→测试→Debug 闭环

开篇的 coding agent 示例已经展示了完整流程（参见上文 SQL）。这里补充做法要点：

做法：先准备输入表和结果模板 → 每轮测试 Fork 一份隔离库 → 在隔离库里再 Fork 两张结果表 → 表 A 执行业务逻辑（AI 写的代码）→ 表 B 用 SQL 写入预期结果 → DIFF 对比 A 与 B → 无差异则通过，有差异则把差异点反馈给 Agent 改代码，重新跑测试。

价值：AI 写代码 → 自动化测试 → 差异可定位 → 反馈 Agent 修改 → 再测，完成「写代码→测试→debug」闭环。DIFF 没有输出即通过，有输出则冲突行 = 值不对，独有行 = 多了或少了一条，差异精确到行和值，可直接回传给 Agent。

场景 2：AI Agent 开发与上线（数据修改）

内核：与场景 1 不同，这里 Agent 改的不是代码而是数据本身（如标注、清洗）。需要验证改动是否符合预期，并支持灰度上线。

做法：Agent 在 Fork 出的库或表上改；自测时 DIFF 验证数据变动；上生产时 Fork 灰度副本 → 小流量 → DIFF 检查 → MERGE 切回。

-- Agent 开发：先 Fork 一份实验库，在副本上改
FORK DATABASE prod TO exp_labeled_data_v2;
-- Agent 执行标注逻辑，写入 exp_labeled_data_v2.labeled_data ...
-- 自测：DIFF 验证改动是否符合预期
DIFF TABLE exp_labeled_data_v2.labeled_data AGAINST prod.labeled_data;
-- 上生产：Fork 灰度库，切小流量，跑一段时间后
FORK DATABASE prod TO prod_gray;
-- 小流量写入 prod_gray.labeled_data ...
-- 检查无异常后
DIFF TABLE prod_gray.labeled_data AGAINST prod.labeled_data;
MERGE TABLE prod_gray.labeled_data INTO prod.labeled_data STRATEGY THEIRS;

整个流程和代码的 PR Review → Merge 一一对应：Fork 是建分支，DIFF 是看 diff，MERGE 是合并。数据变更也有了 Code Review 的能力。

场景 3：实验结果回收与分析

内核：新功能上线前要做实验（随机分流或按标签人群），传统做法是在代码里埋逻辑，实验回收时专门人写一堆 SQL 结合前端埋点做分析，流程重、周期长。用 DIFF 可以直接对比实验组与对照组的结果表，差异行里带 age、标签等维度，一眼看出「哪个年龄段/人群差异大」。

做法：先基于同一份基线用户集 Fork 出实验组和对照组两张表（结构相同，含 user_id、age、标签等）；实验流量分别写入这两个副本；DIFF 对比两表，冲突行 = 同一用户在不同组的行为差异，独有行 = 仅在一组出现的用户；差异行里带 age 等信息，可直接分析「点击这个按钮的人哪个年龄段比较多」。

-- 基线用户集：先落一份对照组数据
CREATE TABLE exp.clicks_base (user_id INT PRIMARY KEY, age INT, click_count INT);
INSERT INTO exp.clicks_base VALUES(1, 25, 2), (2, 35, 4), (4, 45, 1);
-- 基于同一份基线 Fork 出实验组和对照组
FORK TABLE exp.clicks_base TO exp.control_clicks;
FORK TABLE exp.clicks_base TO exp.experiment_clicks;
-- 实验组写入新按钮流量后的结果
UPDATE exp.experiment_clicks SET click_count = 3 WHERE user_id = 1;
UPDATE exp.experiment_clicks SET click_count = 5 WHERE user_id = 2;
DELETE FROM exp.experiment_clicks WHERE user_id = 4;
INSERT INTO exp.experiment_clicks VALUES(3, 25, 2);
-- DIFF 对比：差异行直接带 age，可分析「哪个年龄段在实验组有更多点击」
DIFF TABLE exp.experiment_clicks AGAINST exp.control_clicks;
-- 冲突行 = 同一 user_id 在两组的 click_count 不同（如 user_id=1: 2 vs 3）
-- 独有行 = 仅在一组出现的用户（如 user_id=3 实验组独有，user_id=4 对照组独有），含 age
-- 差异行自带 age，按 age 聚合即可回答「哪个年龄段差异大」

价值：实验回收不用再写一堆 JOIN 和对比 SQL，DIFF 直接给出差异，差异行自带维度信息，分析效率提升。

场景 4：多分支开发——拉分支同时 Fork 新库

内核：代码从 master 拉分支，测试库却共用一套。A 的测试数据污染 B 的环境，B 改的表让 A 的用例挂掉；CI 跑不通、问题难复现、「本地能跑，一合就乱」。

做法：拉新分支时 Fork 新库，每人独享；随时 DIFF 查看改动；合并代码时 MERGE 合回数据。

-- 开发者 A：Fork 并修改
FORK DATABASE test_db TO test_db_feature_a;
UPDATE test_db_feature_a.orders SET status = 'shipped' WHERE id = 1;
INSERT INTO test_db_feature_a.orders VALUES(10, 100, 99.9, 'pending');
-- 合并前查看改动
DIFF TABLE test_db_feature_a.orders AGAINST test_db.orders;
-- 确认后合回
MERGE TABLE test_db_feature_a.orders INTO test_db.orders STRATEGY THEIRS;

场景 5：多团队并行改同一份数据

-- 风控线 Fork 并修改
FORK DATABASE prod TO prod_riskfix;
UPDATE prod_riskfix.orders SET risk_flag = 1 WHERE order_id = 10002;
-- 活动线 Fork 并修改
FORK DATABASE prod TO prod_promo;
UPDATE prod_promo.orders SET amount = amount * 0.9 WHERE order_id IN (10001, 10002);
-- 先合风控
MERGE TABLE prod_riskfix.orders INTO prod.orders STRATEGY THEIRS;
-- 再合活动（若有冲突，选 THEIRS 或 OURS）
DIFF TABLE prod_promo.orders AGAINST prod.orders;
MERGE TABLE prod_promo.orders INTO prod.orders STRATEGY THEIRS;

内核：风控、运营、算法同时改同一张表，「你先改还是我先改」协调成本高，冲突全靠人工对表、拉群沟通。

做法：风控、运营、算法各 Fork 分支，各自改完；DIFF 检查冲突，按业务选 THEIRS 或 OURS 合并。

每个团队在自己的分支里工作，互不干扰。合并时 DIFF 清楚地列出冲突行，按业务规则选择策略，不再需要人工逐行对比。

场景 6：AI 模型训练与标注迭代

内核：与场景 2 类似，但侧重模型训练迭代。标注、调参、重训直接动主表，风险大；改了多少、该不该合回，说不清，也不敢合。

做法：Fork 实验库，在副本上做标注、调参，主表不动；DIFF 量化改动，验证通过后 MERGE 合回。

-- Fork 出实验库
FORK DATABASE prod TO exp_training_data_v2;
-- 在 exp_training_data_v2.training_data 上做新标注、调参 ...
-- 查看改动量
DIFF TABLE exp_training_data_v2.training_data AGAINST prod.training_data;
-- 验证通过后合回
MERGE TABLE exp_training_data_v2.training_data INTO prod.training_data STRATEGY THEIRS;

场景 7：数据同步与跨环境合并

内核：远端数据导回来，新增多少、有没有冲突，要手写一堆 SQL 才能对比，容易漏、容易错。

做法：先 Fork 一本地工作库，再把远端快照导入工作库中的隔离表；DIFF 预览新增与冲突，MERGE 按策略合入。

-- 先 Fork 一本地工作库
FORK DATABASE local TO sync_workspace;
-- 远端数据已导入 sync_workspace.remote_snapshot
-- 预览差异
DIFF TABLE sync_workspace.remote_snapshot AGAINST local.main_table;
-- 以远端为准合入
MERGE TABLE sync_workspace.remote_snapshot INTO local.main_table STRATEGY THEIRS;
-- 或以本地为准，只补新增
MERGE TABLE sync_workspace.remote_snapshot INTO local.main_table STRATEGY OURS;

场景 8：数据质量校验与审计

内核：预期表和实际表的对比是质量校验和回归测试中的常见需求。传统做法是写复杂的 JOIN 和 CASE WHEN 来发现不一致，维护成本高，容易漏。

做法：先 Fork 一份待审数据副本，再用一条 DIFF 发现预期表与实际表的差异。

-- 预期表 qa.expected，待审副本 qa.actual_review 由生产表 Fork 而来
FORK TABLE prod.actual TO qa.actual_review;
DIFF TABLE qa.actual_review AGAINST qa.expected;
-- 有输出即表示存在不一致（冲突=值不同，独有=缺失或多余）

一条 DIFF 替代一堆 JOIN，差异结果精确到行和值，冲突行代表值不同，独有行代表缺失或多余。