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。
=====================================================================================================
如何监控主从延迟：
1.pt-heartbeat工具: -------极度依赖系统时间，要求两系统时间无差
(1)首先针对主库执行，定期更新主库的心跳表。
pt-heartbeat -h 192.168.244.10 -upt_user -p pt_pass --database percona --update -daemonize
其中的参数解释如下。
口--update:对于主库，必须指定--update，它会以每秒一次的频率更新 heartbeat 表。
口--database:heartbeat表所属的数据库。在使用前，必须手动创建。
口--daemonize:让脚本以后台进程的方式运行。
注意，如果是第一次运行，还需指定--create-table，创建heartbeat表
(2)其次针对从库执行，检查从库的主从延迟情况。
此时，需指定--monitor或者--check，其中--monitor是持续检测，每秒输出一次。例如:
pt-heartbeat -h 192.168,244,20 -u pt_user -p pt pass --database percona --monitor
113.00s[1.88s，0.38s，0.13s3.785]
输出一共有4列，第1列是当前的延迟时间,第2、第3、第4列分别是最近1分钟、5分钟和15分钟内的平均延迟情况。
也可指定--check，只检测一次。例如:
pt-heartbeat -h 192.168.244.20 -u pt_user -p pt_pass --database percona --check
2.mysql8.0 原生解决方案：
MySQL 8.0原生的解决方案。它主要基于 performance_schema.replication_applier_status_by_worker 中的 APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP,
这个字段记录了当前正在重放的事务在主库的提交时间。
所以，可通过以下SQL查看主从延迟情况:
select case
when min_commit_timestamp is null then 0
else unix_timestamp(now(6))-unix_timestamp(min_commit_timestamp)
end as seconds_behind_master
from(
select min(applying_transaction_original_commit_timestamp) as min_commit_timestamp
from performance_schema.replication_applier_status_by_worker
where applying_transaction <>''
)t;
这条 SOL语句同样适用于多线程复制。
