數據庫變更是日常開發和運維裏繞不開的活。為了降低線上環境出故障的風險，通常會配合工單系統來發布變更，這樣流程可控，也能減少低級錯誤。市面上能選的工具不少，有開源的，也有商業化的。這次我挑了四款比較常見的：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 在同一個工單中混合使用。子賬號如果在可視化操作過程中沒有對應權限，系統會幫助用户快速創建對應的工單，方便繼續走流程。

通過修改環境策略，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