mysqlsecond_behind_master解读

second_behind_master解读：
  second_behind_master=从库当前的系统时间-SQL线程当前重放的事务在主库的开始时间戳-主从之间的系统时间差（这个一般没有）。

=======
通过上述代码（省略），我们可以得出如下结论：
1.Seconds_Behind_Master为0 的条件是SQL线程已经重放完所有的relay log且slave_IO_Running为 Yes。
2.在以下两种情况中，Seconds Behind_Master会为NULL。
  Slave_SQL_Running为No。
  Slave_SQL_Running为Yes，在重放完所有的relay log时，Slave_I0_Running 不为 Yes。

但是上面的伪代码并没有说明seconds_Behind_Master 具体是如何计算的，所以接下来我们看看对应的源码（省略）。
但在具体计算时，针对 STATEMENT格式和 ROW格式的计算方法又不相同，来看下面这个测试（省略）：
1.statement格式:
  当 seconds_Behind_Master达到最大值时,从库的系统时间是 09:53:43,且主从时间一致。09:53:43减去 9:53:25 等于 18秒，但为何此时 Seconds_Behind_Master 的值是9秒呢?
  由于减去了sql在主库的执行时间： 所以 对于statement格式  second_behind_master=从库当前的系统时间-SQL线程当前重放的事务在主库的开始时间戳-exec_time-主从之间的系统时间差（这个一般没有）。
2.row格式:
  从库的主机时间是10:07:42，事务开始执行的时间是10:07:18，由于主从时间同步，10:07:42减去10:07:18等于24秒，和Seconds_Behind_Master 的最大值 24秒吻合。

=========
Seconds Behind_Master的局限性：
通过上面的分析，我们对 Seconds_Behind_Master 已经有了比较深人的了解。接下来，我们说说它的局限性。
1.Seconds_Behind_Master 只能衡量 SQL线程的延迟情况，不能衡量 IO 线程的延迟情况。
  考虑以下3种场景：
   1.出于网络原因，主库的binlog不能及时发送到从库上。
   2.从库磁盘 IO达到瓶颈，导致主库的二进制日志事件无法及时写人relay log。
   3.参数 slave_net_timeout 设置得较大，在复制的过程中，如果主从网络断开，从库不会及时感知到。
  在上面3个场景中，因为从库的relay log已重放完，且io进程状态为yes,所以Seconds_Behind_Master 会显示为0。但实际上，从库已经延迟了。
2.对于STATEMENT格式和ROW格式的事务，Seconds_Behind_Master 的计算逻辑并不一样如果不熟悉这两者之间的区别，就很容易感到困惑。
3.不适用于级联复制场景。如果二级从库出现了延迟,对于其他级别的从库,Seconds_Behind_Master大概率会为0。