在使用 MySQL 做主從復(fù)制、高可用架構(gòu)以及數(shù)據(jù)恢復(fù)時，你一定會遇到一個關(guān)鍵問題：

• binlog 到底應(yīng)該選擇哪種格式？
• STATEMENT、ROW、MIXED 有什么區(qū)別？
• 是否會影響主從一致性、性能、日志大??？

網(wǎng)上資料大多只講概念，不講“為什么這樣設(shè)計、實際工程里應(yīng)該怎么選”。

這篇文章蒜皮會從 原理機(jī)制 → 真實案例 → 實戰(zhàn)選擇 三條線講透，讓你徹底理解這三種格式的本質(zhì)差異。

一、binlog 是什么？為什么格式如此重要？（應(yīng)用視角理解）

binlog（Binary Log）是 MySQL 最重要的日志之一，用途包括：

• 主從復(fù)制
• 主庫崩潰后的數(shù)據(jù)恢復(fù)
• 回滾誤刪數(shù)據(jù)（閃回）
• 追溯歷史變更
• CDC 變更流服務(wù)（Debezium、Canal）

而 binlog 的格式?jīng)Q定：

• 記錄內(nèi)容的粒度（SQL 級 vs 行級）
• 從庫能否完整重放主庫行為
• 是否會產(chǎn)生主從不一致
• 日志大小、復(fù)制性能、系統(tǒng)吞吐

這就是 binlog 格式如此關(guān)鍵的原因。

MySQL 提供三種格式：

• STATEMENT：記錄 SQL
• ROW：記錄每行變更
• MIXED：混合模式，由 MySQL 自行判斷

接下來我把每一種講透，讓你真正理解區(qū)別。

二、STATEMENT 格式：記錄的是 SQL（輕量但風(fēng)險最大）

STATEMENT binlog 記錄的內(nèi)容是 “你執(zhí)行的 SQL 文本”。

例如：

UPDATE user SET score = score + 1 WHERE id = 1;

binlog 內(nèi)容類似：

statement: UPDATE user SET score = score + 1 WHERE id = 1;

優(yōu)點（非常明顯）

• binlog 最小
• 寫入速度最快
• 主從同步壓力最低
• 非常節(jié)省 IO

這在 數(shù)據(jù)量巨大、有大量寫入 的系統(tǒng)中很有吸引力。

缺點（致命且不可忽視）

很多 SQL 是“不確定的”，比如：

• NOW()
• UUID()
• RAND()
• LOAD_FILE()
• LIMIT
• CURRENT_TIMESTAMP
• 非唯一條件 WHERE（可能鎖不同的行）

例如：

UPDATE user SET last_login = NOW() WHERE id = 100;

主庫時間與從庫時間不一致，會造成：

主從數(shù)據(jù)不一致（fatal）。

這也是為什么 STATEMENT 已經(jīng) 不推薦在生產(chǎn)環(huán)境使用。

三、ROW 格式：記錄的是行級變化（最安全）

ROW binlog 記錄每一行的變動，而不是 SQL。

同樣一條 SQL：

UPDATE user SET score = score + 1 WHERE id = 1;

ROW 格式 binlog 會生成：

before image: {id:1, score:99}
after image:  {id:1, score:100}

注意：并非一個 SQL 一條日志，而是每行變化一條日志。

這意味著：

• SQL 有沒有隨機(jī)函數(shù)都沒關(guān)系
• SQL 有沒有副作用都沒關(guān)系
• SQL 有沒有 WHERE 條件都沒關(guān)系

從庫只需要：

拿著 ROW 日志按順序重放即可，100% 重現(xiàn)主庫行為。

優(yōu)點（強(qiáng)一致系統(tǒng)首選）

• 主從幾乎不可能不一致
• 任何 SQL 都能正確重放
• 支持閃回、審計、CDC 等上層應(yīng)用
• 對數(shù)據(jù)恢復(fù)非常友好

這就是支付、訂單、核心交易系統(tǒng)統(tǒng)一使用 ROW 模式的原因。

缺點（唯一明顯的缺點）

• 日志可能非常巨大
• 批量操作日志量數(shù)十倍增加
• IO 變高
• 復(fù)制壓力變大

例如：

UPDATE user SET status=1 WHERE level in (1,2,3)

如果影響 50 萬行 → row event 就會產(chǎn)生 50 萬條。

對磁盤、網(wǎng)絡(luò)、從庫重放壓力巨大。

四、MIXED 格式：兩種模式的折中（讓 MySQL 自動判斷）

MIXED 模式是：

• SQL 確定性 → 記錄為 STATEMENT
• SQL 不安全/不確定性 → 記錄為 ROW

例如：

UPDATE user SET score = score + 1 WHERE id = 1;   → Statement
UPDATE user SET last_login = NOW();               → Row 

MIXED 本質(zhì)上是一個“自動策略引擎”。

優(yōu)點

• 大部分查詢走 STATEMENT（輕量）
• 存在風(fēng)險時自動降級為 ROW（安全）
• 兼顧性能和安全
• 是很多互聯(lián)網(wǎng)業(yè)務(wù)的默認(rèn)選擇

缺點

• 日志格式不可控
• 運維審計不穩(wěn)定（同一業(yè)務(wù)可能輸出兩種格式）
• 不能用于某些嚴(yán)格一致場景（FTX、交易）

五、怎么選擇 binlog 格式

選擇策略非常簡單：

① 金融、支付、訂單、交易系統(tǒng) → 必須 ROW

原因：

• 不能丟數(shù)據(jù)
• 不能出現(xiàn)主從不一致
• 必須完全可重放

這是行業(yè)硬規(guī)則。

② 大部分互聯(lián)網(wǎng)業(yè)務(wù) → MIXED 最合適

理由：

• 性能與一致性平衡
• 主從延遲不至于太大
• 運維成本可控
• 寫操作規(guī)模不算巨大時，ROW 的劣勢可以接受

③ 寫很少的系統(tǒng) 或 離線數(shù)據(jù)倉庫 → STATEMENT

如：

• 報表
• 數(shù)據(jù)同步平臺
• OLAP 系統(tǒng)

原因：

• 寫少 → 不一致風(fēng)險小
• 讀多 → 記錄 SQL 最輕量

六、總結(jié)：理解 binlog 格式，就是理解 MySQL 復(fù)制的底層邏輯

一句話總結(jié)全文：

STATEMENT 更輕但不安全，ROW 最安全但最大，MIXED 是折中策略。強(qiáng)一致用 ROW，一般業(yè)務(wù)用 MIXED，讀多寫少可考慮 STATEMENT。

binlog 格式不是一個簡單參數(shù)，而是以下的關(guān)鍵設(shè)計點：

• 主從復(fù)制是否可靠
• 數(shù)據(jù)恢復(fù)是否完整
• 業(yè)務(wù)安全性是否有保障

到此這篇關(guān)于MySQL binlog三種格式(STATEMENT / ROW / MIXED)的深度解析的文章就介紹到這了,更多相關(guān)MySQL binlog內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論