這次單獨調查一下主從延遲的時間。這裡說的主從延遲，並不是指“從庫更新效能跟不上主庫”， 而是“一個命令從主庫更新完成到從庫更新完成的延遲時間。

基本流程：

對於每一個連上來的從庫，主庫都有一個client執行緒與之對應。

先看主從的基本資料流

1、客戶端SQL更新命令

2、主庫執行

3、主庫寫binlog

4、主庫client執行緒讀binlog傳送給從庫的io執行緒

5、從庫io執行緒寫盤（relay-log）

6、從庫sql執行緒讀relay-log

7、執行更新。

   這裡有涉及到兩個寫盤，主庫binlog和從庫的relaylog（3、5）。不過不用擔心不停掃描檔案造成的延遲，因為讀檔案的執行緒是在同一個程序內，每次寫完都會廣播，所以雖然看上去是非同步，實際上延遲並不大。

    我們主要考察步驟2完成瞬間到7開始執行之前的延時。

   實驗方法――一級主從

   實際應用中主從庫機器應該是分開的，這裡也討論這種情況（同機房，不同機器）

可以想象延遲很小，因此在不同機器上輸出時間還需要考慮機器之間的時間同步。設計流程如下：

1、機器A上的MySQL S設定為機器B上的MySQL M的從庫

2、在A上有一個簡單客戶端C，向M發起一個insert操作，這個操作會被同步到S。

3、在C執行mysql_real_query返回時輸出當前系統微秒時間 t1

4、在S上的引擎回撥介面write_row入口處輸出當前系統微秒時間 t2

   則 t2- t1的值是我們需要的結果。

   實驗方法――二級主從

   專案中擔心多個從庫連線一個主庫，影響主庫效能，因此還要在實驗二級級聯主從的延遲時間。

   這種結構下，在第一級從庫上增加了一次寫盤轉發 (sql執行更新後寫本地binlog),

   實驗結果

   一級主從 50~100 us

   二級主從 1.1~1.2 ms