您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 綜合教學

MySQL 無縫遷移四大方案對比：Binlog 解析、觸發器、UDF、中間件

編輯：MySQL 綜合教學

業務變更導致表結構調整，如何在不停機或極短停機下完成資料遷移？本文對比四大主流方案原理、實施步驟、優缺點與適用場景，助您依業務約束選擇最佳路徑。

方案對比總覽

方案	停機時間	實施複雜度	資料一致性	適用場景
定點停機遷移	長（隨資料量線性增長）	低	強	資料量小、可接受停機窗口
Binlog 解析同步	極短（1-2 分鐘）	中高	最終一致	資料量大、有 Binlog、可容忍秒級延遲
觸發器雙寫	極短（1-2 分鐘）	中	強（同步）	表結構變更不大、寫入 QPS 可接受額外開銷
UDF / 中間件攔截	極短	高	視實作而定	已有中間件層、或願意投入開發成本

方案一：定點停機遷移（最原始）

選低峰期，停應用。
執行遷移腳本（mysqldump + 結構調整 + LOAD DATA / INSERT ... SELECT）。
驗證資料 → 切換應用連線字串 → 啟動應用。

缺點：資料量大時停機不可控；優點：邏輯簡單、無額外組件依賴。

方案二：Binlog 解析同步（推薦主流）

原理

解析 Master Binlog（Row 格式最佳），按新表結構轉換寫入新庫。同步追上後，停應用、等延遲歸零、切換。

實施步驟

新庫建立目標表結構。
全量同步：mysqldump --single-transaction --master-data=1 導入新庫。
增量同步：啟動 Binlog 解析程式（自研或用 Canal/Maxwell/Debezium），持續同步增量。
校驗一致性（行數、檢查和、抽樣比對）。
停寫入應用 → 等增量同步完成 → 切換應用指向新庫。

關鍵點

Binlog 必須為 ROW 格式（避免非確定性函數、觸發器副作用）。
解析程式需處理 DDL（表結構變更）同步或暫停同步期間禁止 DDL。
大表分批遷移，控制單表同步時間。

方案三：觸發器雙寫（強一致、無外部依賴）

原理

在舊表建立 AFTER INSERT/UPDATE/DELETE 觸發器，同步寫入新表。全量導入後，開啟主從複寫追平，切換。

實施步驟

新庫建立新表結構。
舊庫建立觸發器：


CREATE TRIGGER trg_tbl_ins AFTER INSERT ON old_tbl FOR EACH ROW
BEGIN
    INSERT INTO new_db.new_tbl (col1, col2, ...) VALUES (NEW.col1, NEW.col2, ...);
END;
-- 同理 UPDATE/DELETE

全量導入舊表資料到新表（觸發器會重複寫入新增資料，需去重或用 REPLACE/INSERT IGNORE）。
啟動主從複寫（新庫作為 Slave）追平增量。
停應用 → 確認同步完成 → 切換。

優缺點

優：強一致、無外部組件、資料庫原生支援。
缺：寫入路徑增加開銷（觸發器執行時間加到原交易）、DDL 變更需同步修改觸發器、觸發器除錯困難。

方案四：UDF / 中間件攔截（架構層面解耦）

UDF 方案

編寫 MySQL UDF（C/C++），在 INSERT/UPDATE/DELETE 時推送資料到外部系統（如 Kafka、HTTP、另一 MySQL）。
現成庫：lib_mysqludf_json + memcached_functions_mysql，將變更序列化為 JSON 推送到 Memcached 協定端點，消費端寫入新庫。