MySQL預存程序、函數與復制相容性深度解析：安全策略、限制條件、最佳實踐

核心相容性確認

1. 預存程序/函數對復制有效嗎？

✅ 有效。主庫執行的預存程序/函數內部標準 DML 操作會被復制到從庫。

2. 主庫建立的程式物件會復制到從庫嗎？

✅ 會。CREATE/ALTER/DROP PROCEDURE/FUNCTION DDL 語句會被復制，從庫擁有相同物件定義。

3. 復制行為在程式內部如何發生？

🔑 行級事件復制：MySQL 記錄程式內部發生的每個 DML 事件 (行變更)，將這些單獨 DML 語句復制到從庫。CALL 呼叫本身不被復制。

復制環境安全性要求 (二選一)

前提：啟用 Binlog (復制或 PITR)。

五大復制限制與陷阱

1. 非確定性/隨機函數結果不一致

• RAND()、UUID()、NOW()、SYSDATE() 在主從產生不同值
• 宣告 DETERMINISTIC 僅影響是否允許建立，不保證復制一致性
• ✅ 解決：應用層生成隨機值作為參數傳入

2. 時間基準邏輯無法重現

• 程式中使用 IF HOUR(NOW()) > 18 THEN ... 等時間判斷
• Binlog 僅記錄 DML，**不含時間上下文**，從庫重放時時間已不同
• ✅ 解決：時間判斷移至應用層，以參數傳入

3. 大量 DML 中非交易表部分更新風險

• MyISAM 等非交易表執行大批 INSERT/UPDATE 發生錯誤
• 主庫可能部分完成更新，從庫因錯誤完全無更新 → 主從不一致
• 函數內 DML：自動以 IGNORE 執行，主庫錯誤被忽略，不復制錯誤更新

4. 主鍵衝突導致復制中斷

• 雙主/多主場景 AUTO_INCREMENT 衝突
• ✅ 解決：設定 auto_increment_offset/auto_increment_increment 錯開 ID 空間

5. 版本不一致導致語法/語義差異

• 主從 MySQL 版本不同可能導致預存程序語法解析失敗
• ✅ 解決：主從版本嚴格一致

最佳實踐總結

1. 預存程序設計：純確定性邏輯、參數化所有外部輸入 (含時間、隨機值)
2. 關鍵業務使用 InnoDB 交易，避免非交易表大批操作
3. 部署 Checksum 定期驗證 (pt-table-checksum) 針對高頻程式操作表
4. 監控 Seconds_Behind_Master、Slave_SQL_Running_State 異常告警
5. 文件化所有預存程序輸入參數契約、副作用說明、復制影響評估