這次單獨調查一下主從延遲的時間。這裡說的主從延遲，并不是指“從庫更新性能跟不上主庫”， 而是“一個指令從主庫更新完成到從庫更新完成的延遲時間。
基本流程：
對于每一個連上來的從庫，主庫都有一個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