MySQL 5.6 主從復制深度解析：觸發器、函數、存儲過程與事件的處理機制

三、存儲過程

SBR 模式

• 主庫調用 → 記錄 CALL proc() 到 Binlog → 從庫重放調用。
• 從庫必須存在相同定義，且 DEFINER 一致。
• 確定性要求：過程必須是 DETERMINISTIC 或 READS SQL DATA/NO SQL，且不修改數據。若包含 UUID()、RAND() 等非確定性函數，主從執行結果不同 → 數據不一致。

RBR 模式

• 主庫執行過程 → 產生的行變更寫入 Binlog → 從庫應用行變更。
• 從庫無需定義過程，天然避免確定性問題，復制更健壯。

四、用戶定義函數 (UDF)

• SBR：同存儲過程，主從雙執行，從庫需定義，必須聲明 DETERMINISTIC。非確定性函數 (如 UUID(), MD5()) 導致主從數據分歧。
• RBR：主庫執行函數計算值 → 行變更入 Binlog → 從庫只應用結果。從庫無需函數定義，無確定性風險。

五、調度事件

• 主庫創建 CREATE EVENT → 同步到從庫 (默認 DISABLED)。
• 若從庫手動 ENABLE 該事件，將導致雙重執行：主庫按計劃執行並復制 SQL，從庫本地也按計劃執行 → 嚴重數據不一致。
• 生產建議：從庫事件保持 DISABLED，或僅在主庫故障切換後人工啟用。

六、官方文檔與社區博客的關鍵差異 (存儲過程)

部分舊版博客 (如 LinuxIDC 轉載的 5.5 內容) 認為 SBR 下存儲過程「通過系統函數轉換後的值復制，從庫無需定義」，這與 5.6 官方文檔矛盾。官方明確：SBR 記錄 CALL 語句，從庫重放調用，**必須有定義**。請以官方文檔為準，實測驗證為先。

七、最佳實踐總結

1. 優先使用 RBR (binlog_format=ROW)：觸發器/過程/函數僅主庫執行，從庫無需定義，天然規避確定性與 DEFINER 問題，復制最健壯。
2. 能不用觸發器、存儲過程就不用：業務邏輯下沉應用層，減少資料庫端複雜度與復制風險。
3. 必須用 SBR 時：所有函數/過程聲明 DETERMINISTIC，確保主從 DEFINER 用戶一致，嚴禁非確定性函數。
4. 事件從庫保持 DISABLED，僅作為故障切換備用。
5. 上線前必做實測：構建主從環境，驗證具體業務場景下的復制行為，文檔與實際偶有出入。