>rli.last_master_timestamp值的更新逻辑是怎样的呢？
主要有两个地方：
其一，rpl_rli.cc/Relay_log_info::stmt_done
每次从relay log解析出一条binlog event执行时，last_master_timestamp= event_creation_time;
其二，slave.cc/static Log_event* next_event(Relay_log_info* rli)
进入到下面逻辑的前提条件是relay log已经执行完了，SQL线程在等待relay log有更新
4686 time_t save_timestamp= rli->last_master_timestamp; //先把最后一次处理的binlog event timestamp保存起来，等将来主库又推了binlog过来后第一次计算sbm时就可以用了，这也是为什么有时候start slave后第一次show slave status看到sbm值非常大的一个原因
4687 rli->last_master_timestamp= 0; //把值设为0，那么前面的三元表达式计算的sbm就是0
... 省略部分代码
4779 rli->relay_log.wait_for_update_relay_log(rli->sql_thd); //等待relay log有更新
4780 // re-acquire data lock since we released it earlier
4781 mysql_mutex_lock(&rli->data_lock);
4782 rli->last_master_timestamp= save_timestamp; //重新设置回原值
4783 continue;
然后再来第二个大问题：Seconds_Behind_Master是否可靠？其值为0是否表示主从数据完全一致？
答案必然是否定的。
1. sbm是表示的是relay log中event的延时，而MySQL默认复制是异步的，因此可能从库relay log执行完，但是主从由于网络以及这种原因主库上的binlog没有推送过来，而且我们实际线上也遇到过由于网络原因sbm=0，但主库的binlog根本就没推送过来，一般此时通过stop slave/start slave能发现这种假象。所以平常我们去监控主从延时也不会直接用sbm做判断标准，而是主从建立一张heartbeat表，往主库插入一条数据来判断延时情况。
2. 如果主从时间不同步，那么可能导致sbm延时值不准确
3. 5.6如果开启了多线程复制，那么这个值就更加不准了。我这里也很好奇大家的线上5.6如果开启了MTS是怎么来监控主从延时的？
--EOF--