数据库变更是日常开发和运维里绕不开的活。为了降低线上环境出故障的风险,通常会配合工单系统来发布变更,这样流程可控,也能减少低级错误。市面上能选的工具不少,有开源的,也有商业化的。这次我挑了四款比较常见的:Yearning、Archery、Bytebase,还有 CloudDM,从工单场景出发做了一轮体验和横向对比,给大家一些参考。
测评方法
不同工具的功能侧重点不一样,如果各方面都测,反而看不出差别。所以我主要关注最常见的两个场景:业务上线 和数据订正 。测试用的版本主要是社区版/免费版。
业务上线
功能上线通常包括两部分:程序包和数据库脚本。程序包这块一般由 CI/CD 流程接管,这里不展开。数据库变更脚本经常包括一条或多条需要执行的 SQL 语句,以 DDL 为主。在这个场景下,我准备了两个测试点:
- DDL 需要符合一定的规则;
- 工单里可以处理 DDL/DML 混合语句。
-- 添加表
create table biz_model (
id bigint NOT NULL AUTO_INCREMENT,
created_time datetime COMMENT 'Creation timestamp',
updated_time datetime COMMENT 'Last update timestamp',
content varchar(50) NOT NULL COMMENT 'biz body',
PRIMARY KEY (id)
);
-- 初始化数据
insert into biz_model (id, created_time, updated_time, content)
values (1, '2025-05-30 14:02:39', '2025-05-30 14:02:39', '... content1 ...' );
insert into biz_model (id, created_time, updated_time, content)
values (2, '2025-05-30 14:02:39', '2025-05-30 14:02:39', '... content2 ...' );
insert into biz_model (id, created_time, updated_time, content)
values (5275, '2025-05-30 14:02:39', '2025-05-30 14:02:39', '... content3 ...' );
-- 修改老表
alter table admin_user
add biz_id varchar(50) NOT NULL COMMENT 'biz id';
数据订正
数据订正也比较常见,有时候是有 bug,有时候是运维需要。重点是生产库不能停,在持续写入的情况下修改数据有一定概率会失败。因此在这个场景中,我准备了三个测试点:
- 订正需要修复的数据
- 出于某些原因,数据订正语句可能会报错
- 批量化更新大量数据
-- 修复一条数据
update biz_model set content = 'abc' where id = 1;
-- 修复一条数据(模拟 SQL 报错)
update biz_model set content = null where id = 5275;
-- 批量更新数据
update admin_user set biz_id = 0 where created_time > '2025-01-01';
对比一览
先上对比表,直接看测试体验的结果: ![]()
下面来具体聊聊每款产品的使用体验,主要围绕 工单递交 、SQL 审核 、审批流程与工单执行 这几个环节展开。
CloudDM
在 CloudDM 中,对数据库的操作分成三类:数据查询 、CI/CD 和 工单。默认情况下,查询控制台只能执行查询语句,DDL/DML 需要通过工单才能执行。如果需要,也可以修改环境策略,让它成为一个 SQL 客户端。
![]()
创建工单
CloudDM 创建工单时,允许 DDL/DML 在同一个工单中混合使用。子账号如果在可视化操作过程中没有对应权限,系统会帮助用户快速创建对应的工单,方便继续走流程。
![递交 SQL 工单]()
![可视化创建工单]()
通过修改环境策略,CloudDM 可以禁止环境中数据源的工单功能,在只提供查询的环境中,可以更好地保证数据库的安全。
![]()
SQL 审核
CloudDM 内置了 60 多条规则,并且基本适用于支持的 18 种数据源。比较极客的是,CloudDM 的所有规则全部使用特定的 DSL 语言来编写,并且支持自定义新的规则。这意味着除了内置规则之外,还可以根据自己特殊需要使用 DSL 编写个性化规则,免去二次开发的烦恼。
![]()
工单创建时,CloudDM 会自动检查 SQL,并明显地提示检查结果,标出问题 SQL 所在行。有多条语句的情况下,定位问题很快,改起来也方便。
![]()
在对工单进行 SQL 审核时,CloudDM 提供了两个安全级别。如果 SQL 命中了等级较高的 阻塞 级,就不能创建工单,只有 提示 级时可以选择强制递交工单。
![]()
审批流程
CloudDM 有一个内置简易审批程序,可以提供审批的基本功能,也可以对接 钉钉 、飞书 、企业微信作为外部审批流程引擎,完成复杂的审批流程。
![]()
工单执行
CloudDM 支持以事务方式执行工单,并提供 手动、立即、定时 三种执行模式。选择"已手动完成"意味着 DBA 可以自行处理工单,而不是完全交给系统。这在面对大型数据库或复杂 SQL 时更灵活,可以降低 DBMS 系统带来的不确定性。
![]()
CloudDM 支持工单调试功能,在"数据订正"场景里,即使遇到预设的报错,也可以人工介入处理,再继续执行后续 SQL,而不是简单地中断执行。
![]()
小结
亮点
- UI 交互和权限控制结合得不错,操作体验顺滑,也有安全管控措施。
- SQL 审核可以精确定位问题语句所在行,方便排错。
- 审批可以对接钉钉、飞书、企业微信,适合团队协作。
- 工单执行方式灵活(立即 / 定时 / 手动),还能选事务模式。
- 支持工单调试,执行的时候碰到错误 SQL 可以人工介入后继续执行。
不足
- 在工单递交时没有整合查询计划信息。
- 回滚 SQL 需要手动补充,不够自动化。
Bytebase
Bytebase 在产品上有 SQL 编辑器、工单 两种模式。SQL 编辑器可以执行 SQL 语句,而工单用于管控变更发布。Bytebase 的设计中,数据库变更主要依托于 Git 的 CI/CD,同时也提供了页面递交工单。通过页面递交工单的入口在 CI/CD 中通过创建变更计划来实现,分为 Schema 变更 、数据变更两类。
![]()
创建工单
Bytebase 有两种创建工单的方式,一种基于可视化 UI 交互,另一种是纯 SQL 递交。通过 SQL 递交工单时 Bytebase 支持混合 DDL/DML 语句。
![]()
在 Bytebase 创建工单时,SQL 审核默认是非必须环节,即便工单中包含严重的 SQL 错误也可以正常递交工单。因此建议在安全策略中启用 "禁止提交包含错误告警的工单" 选项,防止不符合规范的 SQL 被递交。
![]()
SQL 审核
Bytebase 内置了 111 条审核规则,其中部分可以在不同数据源之间共用,用户可以在 7 种数据源下配置它们。
![]()
Bytebase 在递交工单时可以手动对 SQL 进行检查,需要先 "运行检查",再点击"检查结果图标",方可查看检查结果,结果中会显示问题 SQL 所在行。
![]()
需要注意的是,Bytebase 在进行 SQL 检测时使用自身存储的元信息数据。若在产品之外执行了 DDL 语句,会导致其内部存储的元信息和真实数据库不一致,这种不一致会进一步影响 Bytebase 功能可用性,例如 SQL 在检测环节出现幻觉。
![]()
审批流程
Bytebase 不支持外部流程引擎,但可以在内部定义审批流程。另外社区版本不支持审批功能,需要购买企业版以解锁该功能。
![]()
工单执行
Bytebase 提供了 立即 、定时 两种工单执行方式,虽然没有明确提示,但在实际体验过程中发现 Bytebase 在执行工单 SQL 时会默认启用事务。当工单失败,整个变更会被回滚,由于 DDL 回滚操作需要数据库的支持,因此用户需要谨慎对待 DDL/DML 混合情况的工单。
![]()
Bytebase 不支持工单调试,并默认以事务方式执行。这意味着在我们设计的 "数据订正" 场景中,报错出现后,需要手动将原始工单进行拆分处理。
![]()
Bytebase 支持同一个工单的 SQL 同时在多个数据库作为执行目标,这个功能可以避免在多环境中递交多个工单。
![]()
小结
亮点
- 工单模式和编辑器模式分工明确,更聚焦不同场景下的需求。
- 可视化生成 SQL 并提交工单,可以降低写错 SQL 的概率。
- 审核结果能精准定位问题 SQL 行,方便排查。
- 可以将多个数据库作为目标,简化多环境发布流程。
不足
- 产品会存储数据库元信息,当多种工具结合运维数据库时容易出现问题。
- 社区版本不支持审批功能,并且产品不支持对接钉钉、飞书等外部审批引擎。
- 工单不能调试,在数据订正场景中遇到错误后需要手动拆分工单。
Archery
Archery 是开源免费的数据库审核工具,它对数据库的操作分为 SQL 查询 和 SQL 上线 ,并且包含一定的 数据库运维能力。查询控制台只支持查询类语句,并且不支持查看数据库对象。所有 DDL、DML 语句都需要通过工单才能执行。
![]()
创建工单
在 Archery 中工单递交允许 DDL/DML 混合使用。
![]()
SQL 审核
在提交工单时,Archery 会清晰地提示 SQL 审核结果,并在支持的情况下会将查询计划及每条 SQL 语句集合在一起展示。若 SQL 命中高等级的 Error 规则,工单将无法递交;而命中 Warning 级规则时,系统会提示,但仍可继续递交工单。
![对于工单 SQL 检查]()
受限于 goInception 的数据源支持,Archery 在 SQL 审核上仅支持 MySQL、Oracle 和 MongoDB,审核规则数量有限且不支持自定义配置。
![]()
审批流程
Archery 无法接入外部流程引擎,但可以通过内部特有的方式定义基于权限组的简单审批流程,工单会在不同权限组之间流转,用户可以加入特定权限组参与审批。
![]()
工单执行
Archery 在工单执行时提供"手动完成"选项,允许 DBA 自己处理工单,而不是完全依赖系统。对于大型数据库或复杂 SQL,这提供了更灵活的操作方式,能有效降低 DBMS 系统带来的不确定性。(该功能默认关闭,需要手动开启)
![]()
Archery 不能调试工单,也不具备事务模式,这意味着在处理强一致性的"数据订正"工单时,DBA 需要格外谨慎。在 "数据订正" 场景中,预先设置的报错场景触发后,Archery 需要创建新的工单来进行后续处理。
![]()
受限于 goInception 的数据源支持,对于 MySQL、Oracle、MongoDB 以外的数据源,Archery 会将工单内容当作一条语句交给数据库处理。
![]()
小结
亮点
- 全部功能开源且免费,在遵守开源协议的前提下可以自由定制。
- 在工单中可以混合使用 DDL/DML,在变更发布需要初始化数据的时候会方便很多。
- SQL 审核结果中整合了查询计划,有助于识别潜在风险 SQL。
不足
- 受限于 goInception 组件,完整功能只支持 MySQL、Oracle 和 MongoDB。不能配置审核规则,也无法在控制台查看完整的规则列表。
- 工单无法调试,数据订正场景中出现错误时,只能创建新工单来继续处理剩余 SQL,操作不够顺畅。
Yearning
在 Yearning 中,对数据库的操作都通过工单来实现,包括数据库的查询。
![]()
创建工单
Yearning 默认限制每个 DDL 工单只能包含一条语句,需要在规则中将这个限制改为允许执行多条 DDL,否则实际使用中会比较麻烦。
![]()
Yearning 不支持 DDL/DML 语句混合,需要把它们拆成单独的工单分别执行。虽然在需要混合语句的情况下,这种限制会带来一定的不便,但在不同的场景下,拆分或者合并都有各自合理的依据。
![]()
需要格外注意的是,Yearning 工单递交时 "是否回滚" 这个选项的真正动作是生成回滚语句,而不是工单以事务方式执行在遇到错误后自动回滚事务。
![]()
SQL 审核
Yearning 内置 46 条审核规则,其中大部分针对 DDL。目前不支持自定义规则。你可以通过创建 SQL 规范或在全局模式中启用已有规则。
![]()
启用 SQL 规则校验后,Yearning 在提交工单时会对 SQL 进行检查,只有通过审核的 SQL 才能提交。
![]()
在 Yearning 中,SQL 规范是绑定在数据源上的,如果同一个环境中多个数据源想使用相同的规则,就需要为每个数据源进行单独设置。
![]()
审批流程
Yearning 不支持外部流程引擎,但可以通过内置流程引擎进行简单节点定义。
![]()
工单执行
在"数据订正"场景中,Yearning 能在预设的报错语句处成功中止执行。但它不支持报错后的后续处理,如果是一批需要一对一更新的数据,遇到报错后只能新建工单来继续执行剩余 SQL。
![]()
小结
亮点
- 上手门槛很低,基本不需要看文档,仅凭探索就可以上手操作,这一点非常棒。
- 产品非常聚焦,以工单驱动,没有多余复杂的功能,上手体验很轻松。
不足
- 相比其他几款产品,功能比较单一。
- 和其他产品一样,缺少工单调试功能,在数据订正出错时只能再建一个工单处理剩余部分。
总结
这四款 SQL 审核工具在功能和体验上各有优缺点,总体来说:
- 服务支持:所有产品都有免费的社区版本可用,同时 CloudDM、Bytebase 背后有商业公司支撑,提供长期的更新与支持保障。
- 查询控制台:在查询控制台简单体验中,CloudDM、Bytebase 用户体验较为友好,可以很好适配开发环境和生产环境的实际需求。
- 数据源支持:除 Yearning 外所有产品都支持多种数据源。
- 开放性:Archery、Yearning、Bytebase 有开源版本可供选择,但功能限制较多,CloudDM 虽然不开源,但开放的功能是最全面的。
- 工单处理:CloudDM、Archery 允许在平台中标记工单已完成,DBA 可以根据工单内容,自己手动处理 SQL,这个设计给了 DBA 更大的灵活空间来应对一些特殊数据库。
- 回滚:CloudDM 可选是否开启事务;Bytebase 不能选择但默认为事务模式;Archery、Yearning 提供了生成逆向 SQL 的能力。
接下来,我还会继续体验测试其他 SQL 审核工具并分享出来,欢迎持续关注。有不同的想法也欢迎在评论区交流讨论。
更多内容,欢迎关注公号:CloudDM