数据库变更是日常开发和运维里绕不开的活。为了降低线上环境出故障的风险，通常会配合工单系统来发布变更，这样流程可控，也能减少低级错误。市面上能选的工具不少，有开源的，也有商业化的。这次我挑了四款比较常见的：Yearning、Archery、Bytebase ，还有 CloudDM，从工单场景出发做了一轮体验和横向对比，给大家一些参考。
测评方法
不同工具的功能侧重点不一样，如果各方面都测，反而看不出差别。所以我主要关注最常见的两个场景：业务上线 和数据订正 。测试用的版本主要是社区版/免费版。
业务上线
功能上线通常包括两部分：程序包和数据库脚本。程序包这块一般由 CI/CD 流程接管，这里不展开。数据库变更脚本经常包括一条或多条需要执行的 SQL 语句，以 DDL 为主。在这个场景下，我准备了两个测试点：
- DDL 需要符合一定的规则；
- 工单里可以处理 DDL/DML 混合语句。
plain
-- 添加表
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，有时候是运维需要。重点是生产库不能停，在持续写入的情况下修改数据有一定概率会失败。因此在这个场景中，我准备了三个测试点：
- 订正需要修复的数据
- 出于某些原因，数据订正语句可能会报错
- 批量化更新大量数据
plain
-- 修复一条数据
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';对比一览
先上对比表，直接看测试体验的结果：
| 分类 | 功能 | CloudDM | Archery | Yearning | Bytebase |
|---|---|---|---|---|---|
| 数据源 | 可管理的数据源 | 18 种 | 14 种 | 1 种 | 24 种 |
| 数据源 | 支持审核的数据源 | 18 种 | 3 种 | 1 种 | 7 种 |
| 数据源 | 查询控制台 | ✔️ | ✔️ | ✔️ | ✔️ |
| 工单递交 | DDL/DML 混合语句 | ✔️ | ✔️ | ✖️ | ✔️ |
| 工单递交 | 分析查询计划 | ✖️ | ✔️ | ✔️ | ✔️ |
| SQL 审核 | SQL 规则 | 60+ | 10+ | 40+ | 100+ |
| SQL 审核 | 自定义规则 | ✔️ | ✖️ | ✖️ | ✖️ |
| SQL 审核 | 规则参数配置 | ✔️ | ✖️ | ✔️ | ✔️ |
| SQL 审核 | 审核分级 | ✔️ | ✔️ | ✖️ | ✔️ |
| SQL 审核 | 禁止递交问题工单 | ✔️ | ✔️ | ✔️ | ✔️ |
| SQL 审核 | 提示所在行 | ✔️ | ✖️ | ✖️ | ✔️ |
| SQL 审核 | SQL 审核结果回溯 | ✔️ | ✔️ | ✖️ | ✔️ |
| 审批流程 | 内置审批 | ✔️ | ✔️ | ✔️ | 收费 |
| 审批流程 | 自定义审批流 | ✖️ | ✔️ | ✔️ | 收费 |
| 审批流程 | 流程引擎 | 内置 钉钉 飞书 企业微信 | 内置 | 内置 | 内置 |
| 工单执行 | 执行方式 | 立即/定时/手动 | 立即/定时/手动 | 立即/定时 | 立即/定时 |
| 工单执行 | 事务模式 | 可选 | 不支持 | 不支持 | 默认（不可选） |
| 工单执行 | 工单调试 | ✔️ | ✖️ | ✖️ | ✖️ |
| 工单执行 | 工单失败后回滚方式 | 需要事务模式 | 生成语句 | 生成语句 | 事务 |
使用体验
下面来具体聊聊每款产品的使用体验，主要围绕 工单递交 、SQL 审核 、审批流程与工单执行 这几个环节展开。
CloudDM
在 CloudDM 中，对数据库的操作分成三类：数据查询 、CI/CD 和 工单。默认情况下，查询控制台只能执行查询语句，DDL/DML 需要通过工单才能执行。如果需要，也可以修改环境策略，让它成为一个 SQL 客户端。
创建工单
CloudDM 创建工单时，允许 DDL/DML 在同一个工单中混合使用。子账号如果在可视化操作过程中没有对应权限，系统会帮助用户快速创建对应的工单，方便继续走流程。
通过修改环境策略，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 级规则时，系统会提示，但仍可继续递交工单。
受限于 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