MySQL/MariaDB 主從複制中 UUID() 函數不安全警告的成因與解決方案

現象複現

MariaDB 5.5 / MySQL 5.5 主庫錯誤日誌大量出現：

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. 
Statement is unsafe because it uses a system function that may return a different value on the slave. 
Statement: INSERT INTO t_user(userId, userName) VALUES(UUID(), 'FunYoung')

根因分析

1. STATEMENT 格式：Binlog 記錄 SQL 文本，從庫重放時再次執行 UUID()，產生新值，導致主從數據不一致。
2. UUID() 非確定性函數：每次調用返回不同值，屬於「不安全函數」清單成員（同類還有 NOW()、RAND()、SYSDATE() 等）。
3. 版本演進：
   • MySQL 5.0 確實存在缺陷；
   • 5.6 官方文檔宣稱已修正（參考 Changes in MySQL 5.6.0），但實測 5.5 仍報警；
   • MariaDB 5.5 兼容 MySQL 5.5 行為，同樣觸發。

三種解決路徑

方案一：升級至 5.6+ 或 MariaDB 10.2+（推薦）

新版本在 ROW/MIXED 模式下自動處理非確定性函數，或直接將 UUID() 標記為安全。若環境允許升級，此為最徹底方案。

方案二：調整 Binlog 格式為 ROW 或 MIXED

-- 動態生效（重啟失效）
SET GLOBAL binlog_format = 'ROW';
-- 或 MIXED：非確定語句自動切 ROW
SET GLOBAL binlog_format = 'MIXED';

-- 永久生效，編輯 my.cnf
[mysqld]
binlog_format = ROW

影響：ROW 格式體積較大，網絡/磁碟開銷增加；MIXED 為折中。

方案三：應用層生成 UUID（最佳實踐）

將 UUID 生成邏輯下沉到應用代碼（Java UUID.randomUUID()、PHP uniqid()、Go github.com/google/uuid 等），SQL 僅插入已生成的字串：

INSERT INTO t_user(userId, userName) VALUES('a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8', 'FunYoung');

優勢：

• 完全規避 Binlog 格式限制；
• 主從、多主、跨庫同步均安全；
• 應用層可控制版本（v1/v4/v7）與格式。

驗證步驟

-- 主庫執行
INSERT INTO t_user(userId, userName) VALUES(UUID(), 'test');
-- 從庫檢查
SELECT * FROM t_user WHERE userName='test';
-- 對比 userId 是否一致

總結建議

場景	推薦方案
可升級 DB 版本	升級至 5.6+/MariaDB 10.2+，保持 STATEMENT
不可升級、低寫入量	改 binlog_format=MIXED
高併發、強一致性要求	應用層生成 UUID + ROW 格式