Seconds_Behind_Master值的意义

Seconds_Behind_Master
This field is an indication of how “late” the slave is:
• When the slave is actively processing updates, this field shows the difference between the current timestamp on the slave and the original timestamp logged on the master for the most event currently being processed on the slave.
• When no event is currently being processed on the slave, this value is 0.
Seconds_Behind_Master表示slave的数据同步落后于master的状况：
1）当slave正在处理更新，该字段表示当前slave的时间戳与最近在slave上执行的事件（master上记录的，也就是slave上relay-log中的事件）的时间戳的差值。

2）当slave没有事件处理（relay-log），显示的值为0。

In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread. If the network connection between master and slave is fast, the slave I/O thread is very close to the master, so this field is a good approximation of how late the slave SQL thread is compared to the master.If the network is slow, this is not a good approximation;the slave SQL thread may quite often be caught up with the slow-reading slave I/O thread, so Seconds_Behind_Master often shows a value of 0,even if the I/O thread is late compared to the master. In other words, this column is useful only for fast networks.
This time difference computation works even if the master and slave do not have identical clock times, provided that the difference, computed when the slave I/O thread starts, remains constant from then on. Any changes—including NTP updates—can lead to clock skews that can make calculation of Seconds_Behind_Master less reliable.
本质上，Seconds_Behind_Master表示过slave的SQL线程与I/O线程的时间差。只有当网速较快时，Seconds_Behind_Master才能较好的估计slave的SQL线程相对于master的延迟。当master与slave之间的网速较慢时，Seconds_Behind_Master的值通常是0。
This field is NULL (undefined or unknown) if the slave SQL thread is not running, or if the slave I/O thread is not running or is not connected to the master. For example, if the slave I/O thread is running but is not connected to the master and is sleeping for the number of seconds given by the CHANGE MASTER TO statement or --master-connect-retry [1917] option (default 60) before reconnecting, the value is NULL. This is because the slave cannot know what the master is doing, and so cannot say reliably how late it is.
The value of Seconds_Behind_Master is based on the timestamps stored in events, which are preserved through replication. This means that if a master M1 is itself a slave of M0, any event from M1's binary log that originates from M0's binary log has M0's timestamp for that event. This enables MySQL SHOW Syntax to replicate TIMESTAMP successfully. However, the problem for Seconds_Behind_Master is that if M1 also receives direct updates from clients, the Seconds_Behind_Master value randomly fluctuates because sometimes the last event from M1 originates from M0 and sometimes is the result of a direct update on M1.