对于主从库主机时间不一致的情况，在I/O线程第一次启动时，会计算主从之间的主机时间差，在后续计算复制延迟时，会把这个时间差减掉，这样就可以保证正确获取到复制延迟时间，但是该时间差只在I/O线程启动时才会进行计算，所以，当I/O线程启动之后修改了主从库的主机时间，则根据计算公式，会导致复制延迟时间不可靠，但是当I/O线程重启之后就可以恢复（因为I/O线程重启时，主从之间的时间差重新计算了）
在计算复制延迟时（执行 SHOW SLAVE STATUS语句时会进行计算），对Seconds_Behind_Master计算结果做一些判定（上文源码介绍部分的伪代码注释里有讲解过，这里再啰嗦一下）：
* 如果 I/O 和 SQL线程同时为 Yes，且SQL线程没有做任何事情（没有需要被执行的event），此时直接判定复制延迟结果为0，不会走公式计算延迟时间，否则会走公式计算延迟时间（所以，在该前置条件下不会出现当主库没有写任何binlog event时，从库延迟不断加大的情况）
* 如果 SQL线程为Yes，且还存在着 I/O 线程已经读取的relay log未应用完成的，则会走公式计算延迟时间，而不管 I/O线程是否正在运行，但当SQL线程重放完成了所有relay log时，如果 I/O线程不为Yes，直接判定复制延迟结果为NULL
* 任何时候，如果SQL线程不为Yes，直接判定复制延迟结果为NULL。当计算出的复制延迟为负数时，直接归零
来自老叶公众号