首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
您现在的位置: 程式碼之家 >> 數據庫知識 >  >> MySQL 資料庫 >> MySQL 綜合教學

MySQL 複寫同步機制深度解析:Trigger/Procedure/Event 在 STATEMENT/ROW/MIX 模式下的 Binlog 記錄行為

     編輯:MySQL 綜合教學

核心概念回顧

物件定義
Trigger綁定表的事件驅動程式(INSERT/UPDATE/DELETE 觸發)
Procedure預存的 SQL 語句集合,需 CALL 調用
Event定時排程任務,類 Linux crontab

Binlog 格式模式

模式記錄內容特點
STATEMENT原始 SQL 語句體積小,非確定性函數可能導致主從不一致
ROW實際行變更(前後圖)體積大,絕對一致性,不受函數影響
MIXED預設 STATEMENT,必要時切 ROW折衷方案

六大組合場景 Binlog 記錄行為

場景Binlog 記錄內容從庫重放行為
STATEMENT + TriggerCREATE TRIGGER + 觸發的原始 SQL(不記錄 Trigger 內部 SQL)重建 Trigger → 執行原始 SQL → Trigger 自動觸發
ROW + TriggerCREATE TRIGGER + 原始 SQL + Trigger 內部所有行變更重建 Trigger → 重放原始 SQL + 直接應用 Trigger 產生的行變更(不再觸發 Trigger)
STATEMENT + ProcedureCREATE PROCEDURE + Procedure 內部 SQL(展開記錄,不記錄 CALL)重建 Procedure → 重放展開的 SQL
ROW + ProcedureCREATE PROCEDURE + Procedure 產生的所有行變更(不記錄 CALL)重建 Procedure → 直接應用行變更
STATEMENT + EventCREATE EVENT + Event 內部 SQL(展開記錄)重建 Event → 重放展開的 SQL
ROW + EventCREATE EVENT + Event 產生的所有行變更重建 Event → 直接應用行變更

關鍵差異總結

  • STATEMENT 模式:記錄「怎麼做」(SQL),從庫重新執行邏輯,Trigger/Procedure/Event 會在從庫再次觸發/執行
  • ROW 模式:記錄「結果」(行變更),從庫直接應用結果,Trigger/Procedure/Event **不會在從庫再次執行**
  • CREATE 語句永遠以 STATEMENT 記錄:DDL 無 ROW 格式

實務風險與最佳實踐

風險 1:從庫 binlog_format 不一致導致同步中斷

  • 主庫 ROW、從庫 STATEMENT → 從庫無法解析 ROW 事件 → 報錯停止
  • 解決:主從統一 binlog_format,建議統一用 ROW

風險 2:CREATE 觸發隱含 binlog_format 切換

  • 從庫執行 CREATE 時會臨時切換格式,可能衝突

風險 3:非確定性函數在 STATEMENT 模式下主從不一致

  • UUID()、NOW()、RAND() 等在主從產生不同值
  • ROW 模式免疫此問題

建議策略

  1. **生產環境統一使用 ROW 格式**(MySQL 5.7+ 預設即 ROW)
  2. **避免在資料庫層使用 Trigger/Procedure/Event 實現核心業務邏輯**
  3. 改由應用層(Service Layer)控制,資料庫僅做存儲
  4. 若必須用,嚴格測試主從同步行為,文檔化所有邊界情況

驗證指令

  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved