高性能mysql上說，seconds_behind_master這個值就是從服務器在事件開始執行時的系統時間戳與binlog日志中的事件的時間戳相對比得到的。
果真如此嗎？
下面這個測試證明這句話是錯誤的！
主庫對一個上千萬行數據的表執行update table t set name='xxx'，假設00分00秒開始執行，50秒后執行完畢。此時主庫記錄的binlog中的時間是00分00秒(記錄的是事件開始的時間)，而從庫在00分50秒時拿的binlog並執行時seconds_behind_master顯示的卻是0秒、1秒、2秒，依次往上漲直到從庫執行完畢。
結論一：從庫的seconds_behind_master並不是與binlog中的時間戳(此例中是00分00秒)相比較。在此例中這個值看着好像是指io線程拿到事件的時間和sql線程執行這個事件時間差，而參考手冊上就是這么說的，見下。
參考手冊上說，seconds_behind_master測量從屬服務器SQL線程和從屬服務器I/O線程之間的時間差距，單位以秒計。本字段是從屬服務器“落后”多少的一個指示。
果真如此嗎？是從服務器的兩個線程的對比嗎？
下面這個測試證明這句話是錯的！
從庫中斷復制stop slave，3天后開啟(正好在公司環境中發生過)。此時從庫的IO線程去讀取binlog並且sql線程去執行，假設網絡沒有延遲，按參考手冊上的說法，seconds_behind_master應該指io線程拿到事件的時間和這個事件執行的的時間的差值。但實際上卻發現，從庫的seconds_behind_master上來就是3天左右，即從庫中斷的時間。隨着從庫漸漸的追趕主庫，seconds_behind_master越來越小，直到追趕上之后變為0。即seconds_behind_master是和主庫相關聯的。
結論二：從庫的seconds_behind_master並不是從庫的io和sql線程之前的比較，而是與主庫的某個時間比較。
結論二說明seconds_behind_master是與主庫的某個時間相比較得到的；結論一說明並不是與主庫的binlog中的時間做比較得到的。
根據這兩個結論，個人判斷seconds_behind_master是事件在從庫執行的時間與這個事件在主庫提交時的時間來比較。而binlog中的時間是事務開始的時間而不是提交時間。所以最后的問題是：這個事務提交時間在哪里？從庫怎么知道的？
希望有大牛能看到，一起探討。