對於Seconds_Behind_Master，很多人誤以為是從庫落後主庫多少秒，從Seconds_Behind_Master單詞的字面上看也是如此。

但是看看Seconds_Behind_Master的原理就明白了，其延遲是通過備庫當前的時間戳減去SQL執行緒正在執行的SQL語句的時間戳計算出來的。

Seconds_Behind_Master描述延時是不太準確的，比如IO執行緒掛起了，主從有明顯的延時，你會發現Seconds_Behind_Master可能還是0.

可以進行下面兩個測試：

測試一：把備庫當前時間進行調整。

測試二：斷開備庫的網路連線，你會發現Seconds_Behind_Master仍舊為0，備庫過來slave-net-timeout秒還沒有收到主庫來的資料，它就會開始第一次重試。然後每過master-connect-retry秒，備庫會再次嘗試重連主庫。直到重試了master-retry-count次，它才會放棄重試。如果重試的過程中，臉上了主庫，那麼它認為當前主庫是好的，又會開始slave-net-timeout秒的等待。

slave-net-timeout的預設值是3600秒，master-connect-retry預設值是60秒，master-retry-count預設值為86400次。

slave-net-timeout的3600秒的預設值有些大，建議可以設定小一點，比如30秒。

可以使用percona的pt-heartbeat工具計算延時：

原理是在主庫生成一張表，把這個表同步到備庫上，這個表裡記錄時間，在備庫上用當前時間減去表裡時間就得到了延時資料。

表如下：

在主庫上執行：

pt-heartbeat --defaults-file=/usr/local/mysql/my.cnf --database test --update --create-table --deamonize 

說明：

--defaults-file 指定配置檔案

--database 指定資料庫
--update 更新

--create-table  建立表

-deamonize 後臺執行

在從庫上執行：

pt-heartbeat --defaults-file=/usr/local/mysql/my.cnf  -D test --monitor --master-slave-id 1

-defaults-file 指定配置檔案 

 -D 指定資料庫

--monitor 監控

--master-slave-id  指定主庫的server id

第一列的當前延時時間，後面的三列分別是5分鐘、10分鐘、15分鐘的延時。