MySQL 主從復制監控陷阱：ROW 格式 Binlog 導致從庫 Com_insert 不增長的根因與替代指標

唯一差異：binlog_format（Statement vs ROW）。

官方文檔定義

Com_xxx：「每種 xxx 語句執行的次數」。Com_insert 計數 INSERT 語句執行次數（批量插入計 1 次）。

ROW 格式限制：「無法通過日志查看執行了什麼語句，從庫也無法看到接收並執行了什麼語句」。

根因推導

1. 主庫：接收客戶端 INSERT 語句 → 解析執行 → Com_insert++ → 寫入 Binlog（ROW 格式記錄行變更，非語句）。
2. 從庫 SQL 線程：讀取 Relay Log → 解析 ROW 事件 → 直接調用存儲引擎 Write_row 接口寫入數據頁 → 不經過 SQL 解析層 → Com_insert 不增加。
3. 本質：Com_xxx 是 Server 層語句計數器，ROW 復制繞過 Server 層直接進 Engine 層，自然不計數。

替代監控指標：Innodb_rows_inserted

SHOW GLOBAL STATUS LIKE 'Innodb_rows_inserted';
+----------------------+------------+
| Variable_name        | Value      |
+----------------------+------------+
| Innodb_rows_inserted | 2666049650 |
+----------------------+------------+

• 定義：InnoDB 存儲引擎層面實際插入的行數（非語句數）。
• 優勢：無論 Statement/ROW/Mixed 格式，從庫重放行變更時均會遞增，真實反映寫入量。
• 配套指標：Innodb_rows_updated、Innodb_rows_deleted、Innodb_rows_read。

監控體系建議

告警規則示例

# 從庫寫入速率異常（PromQL）
rate(mysql_global_status_innodb_rows_inserted[5m]) < 10
  AND on(instance) rate(mysql_global_status_com_insert[5m]) > 100

# 主從延遲配合行數差異檢測
mysql_slave_status_seconds_behind_master > 30
  AND abs(master_innodb_rows_inserted - slave_innodb_rows_inserted) > 10000

總結

• Com_xxx 只統計 Server 層語句執行，ROW 格式從庫繞過該層 → 計數歸零。
• Innodb_rows_inserted 是 Engine 層行級計數，不受 Binlog 格式影響，才是從庫寫入監控的「金標準」。
• 建立統一監控視圖時，按 binlog_format 分組選擇指標來源，避免誤報。