如何查看MYSQL複製中的延遲？
一般來說我們看Second_Behind_Master的值就可以判斷了，但是並不準確。這篇文字詳細地闡述瞭如何正確的查看複製中的延遲問題。
首先我們需要明確Time值的意義。
mysql > show full processlist\G
*************************** 1. row ***************************
Id: 6
User: system user
Host:
db: NULL
Command: Connect
Time: 22005006
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 7
User: system user
Host:
db: NULL
Command: Connect
Time: 3293
State: Updating
Info: UPDATE ** SET ** WHERE **
在replication 進程中，Time 可能有以下幾種情況：
對於SQL線程：
1.當前沒有活躍SQL時，Time的值就是SQL線程的空閒時間。此時Second_behind_master的值爲0
2.當前有活躍SQL時，Time的值是SQL線程當前執行的relay log中的timestamp與IO線程中最新的timestamp的差值，也就是Second_Behind_Master 的值。
對於IO線程：
Time表示的是IO線程從啓動到現在的總時長。
那麼我們到底應該如何正確判斷Slave的延遲情況呢？
1.首先看Relay_Master_Log_File和Master_Log_File是否有差異；
2.如果沒有差異，說明延遲沒有跨日誌文件。然後我們再看Exec_Master_Log_Pos和Read_Master_Log_Pos的差異，對比SQL線程比IO線程慢多少個binlog events;
3.如果Relay_Master_Log_File和Master_Log_File不一樣，那說明延遲跨日誌文件，需要從Master節點獲取當前binlog和Slave上執行的binglog 的差距。
下面演示步驟：
1.無活躍SQL
Master節點：
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 100596 |
| mysql-bin.000002 | 2265 |
| mysql-bin.000003 | 177 |
| mysql-bin.000004 | 154 |
+------------------+-----------+
4 rows in set (0.00 sec)
Slave節點：
mysql> show slave status\G
*************************** 1. row ***************************
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 154
Relay_Log_File: centos-relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: 154
Seconds_Behind_Master: 0
可以看到此時
Slave_SQL_Running_State: Slave has read all relay log;
Seconds_Behind_Master: 0
說明當前SQL線程空閒，無延遲。
2.存在活躍SQL：
在 MASTER 上執行 SHOW BINARY LOGS 的結果是：
+------------------+--------------+
| Log_name | File_size |
+------------------+--------------+
| mysql-bin.000009 | 1073742063 |
| mysql-bin.000010 | 107374193 |
+------------------+--------------+
而在 SLAVE 上執行 SHOW SLAVE STATUS\G 的結果是：
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
***
Exec_Master_Log_Pos: 654409041
***
Seconds_Behind_Master: 3296
***
這時候， SLAVE 實際的延遲應該是：
mysql-bin.000009 這個 binlog 中的 binlog position 1073742063 和 SLAVE上讀取到的 binlog position 之間的差異延遲：
1073742063 - 654409041 = 419333022 個 binlog events
並且還要加上 mysql-bin.000010 這個 binlog 已經產生的 107374193 個 binlog event，共107374193 + 419333022 = 526707215 個 binlog event
