在MySQL的主从环境中，我们能够通过在slave上运行show slave status来查看slave的一些状态信息，当中有一个比較重要的參数Seconds_Behind_Master。那么你是否明确它的真正含义以及它是怎么计算的呢？
在之前我一直误以为Seconds_Behind_Master是表示slave比master落后多少，假设这个值为0的表示主从已经处于一致了（在非同步模式下，如今官方最多也仅仅在5.5中添加�了半同步复制）。可是近期我最终认识到之前的错误理解。首先我们须要明确的一点：Seconds_Behind_Master表示slave上SQL thread与IO thread之间的延迟，我们都知道在MySQL的复制环境中，slave先从master上将binlog拉取到本地（通过IO thread），然后通过SQL thread将binlog重放，而Seconds_Behind_Master表示本地relaylog中未被运行完的那部分的差值。手冊上的定义：
In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread.
所以假设slave拉取到本地的relaylog（实际上就是binlog，仅仅是在slave上习惯称呼relaylog而已）都运行完，此时通过show slave status看到的会是0，那么Seconds_Behind_Master的值为0是否表示主从已经处于一致了呢?答案差点儿是否定的！为什么差点儿是否定的？由于绝大部分的情况下复制都是异步的，异步就意味着master上的binlog不是实时的发送到slave上，所以即使Seconds_Behind_Master的值为0依旧不能肯定主从处于一致，这也是我之前强调非同步复制的原因（如今已经有公司在做同步复制了，比方网易自己实现了VSR，VirtualSynchronized Replication，由于同步复制性能较差，所以网易再实现同步复制的同一时候还打了group commit的补丁）。所以假设我们要以这个參数来预计主从延迟多久的话至少得在一个比較好的网络环境中，这样才干保证差点儿master上的binlog都已经发送到slave上。
上面解释了Seconds_Behind_Master这个值的真正含义，那么它的值究竟是怎么计算出来的呢？实际上在binlog中每一个binlog events都会附上运行时的timestamp，所以在在确定Seconds_Behind_Master的值时MySQL是通过比較当前系统的时间戳与当前SQL thread正在运行的binlog event的上的时间戳做比較，这个差值就是Seconds_Behind_Master的值。或许你会有疑问那要是两台server之间的时钟不一致怎么办？确实会存在这样的情况，那么此时这个值的可靠性就不大了，手冊上对此也进行了说明：
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的值除了是非负数之外还可能是NULL，它是由例如以下几种情况导致的：SQL thread没执行/IO thread没执行/slave没有连接到master。
接下来再简介一下异步复制/半同步复制之间的差别。
异步复制，master上的操作记录binlog的同一时候不关心binlog是否已经被slave接收。
半同步复制，master上的操作记录binlog的同一时候会关心binlog是否被slave接受。可是因为它的处理逻辑问题可能丢一个事务，例如以下图所看到的：
这种处理流程存在一个问题，当存储引擎提交（storage commit）后，此时假设master挂了那么会存在主从不一致，对于这个问题orczhou好像自己对源代码进行了改动更改storage commit的顺序来达到一个增强的半同步复制。
对Seconds_Behind_Master就解释到这里，希望对你也能有点帮助。