MySQL 從庫延遲監控深度解析：Seconds_Behind_Master 不夠準，正確判斷三步法

單看 Seconds_Behind_Master (SBM) 判斷從庫延遲往往不準。本文分析 SBM 計算邏輯缺陷，提出基於 Binlog 序號與位置的三步精準判斷法。

SBM 的局限性

• SBM = SQL 執行緒正在處理的事件時間戳 與 IO 執行緒最新讀取事件時間戳的差值。
• 若主庫長時間無寫入，SBM 會持續增長（時間戳差變大），實際並無延遲。
• 若主庫大事務執行久，SBM 反映的是事務執行時間，非傳輸延遲。

觀察 SLAVE 兩執行緒狀態

mysql> SHOW FULL PROCESSLIST\G
Id: 6  User: system user  State: Waiting for master to send event  Time: 22005006  -- IO 執行緒，Time=啟動至今秒數
Id: 7  User: system user  State: Updating  Time: 3293  -- SQL 執行緒，Time=SBM 值

SQL 執行緒的 Time 欄位含義：

1. 有活躍 SQL 時：等於 SBM（當前事件時間戳與 IO 線程最新事件時間戳差）。
2. 無活躍 SQL 時：等於 SQL 執行緒閒置時間。

精準判斷三步法

步驟 1：比對 Relay_Master_Log_File vs Master_Log_File

• 相同 → 同一 Binlog 檔案，延遲在同檔內。
• 不同 → 跨檔延遲，需進一步計算。

步驟 2：同檔案時，比對 Exec_Master_Log_Pos vs Read_Master_Log_Pos

• 差值 = SQL 線程落後的 Binlog 事件位移量。

步驟 3：跨檔案時，需從 MASTER 取得最新 Binlog 狀態

-- MASTER
SHOW BINARY LOGS;
+------------------+--------------+
| Log_name         | File_size    |
+------------------+--------------+
| mysql-bin.000009 | 1073742063   |
| mysql-bin.000010 | 107374193    |
+------------------+--------------+

-- SLAVE
Relay_Master_Log_File: mysql-bin.000009
Exec_Master_Log_Pos: 654409041
Read_Master_Log_Pos: 668711237

實際延遲計算

1. 當前 Binlog (mysql-bin.000009) 總大小 1,073,742,063 位元組。
2. SQL 線程已執行至 654,409,041，落後 1,073,742,063 - 654,409,041 = 419,333,022 位元組。
3. 加上下一個 Binlog (mysql-bin.000010) 已產生 107,374,193 位元組。
4. 總落後 ≈ 526,707,215 位元組（Binlog 事件位移量）。

監控系統實作建議

1. 監控節點同時對 MASTER 執行 SHOW BINARY LOGS、對 SLAVE 執行 SHOW SLAVE STATUS。
2. 計算 Binlog 檔案差異 + 位移差異，得出位元組級延遲指標。
3. 結合 Relay_Log_Space（Relay Log 總大小）判斷 IO 線程是否跟得上。
4. 設定告警閾值：位移差 > 100MB 或檔案差 > 1 個 Binlog。

此法能準確量化延遲規模，避免 SBM 誤導。