以如下一个数据为例
: mysql-bin.028475
Read_Master_Log_Pos: 973706298
Relay_Log_File: relay-bin.061277
Relay_Log_Pos: 973586576
Relay_Master_Log_File: mysql-bin.028475
Exec_Master_Log_Pos: 973586443
Seconds_Behind_Master: 0
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 486e3366-d9f2-11ea-a611-a01c8d23694a:1-2552456981
Executed_Gtid_Set: 48686533-d9f2-11ea-b1ba-a01c8d7dfb7f:1-361655173,
486bfa3b-d9f2-11ea-8b02-a01c8d40b01a:1-1549384212,
486e3366-d9f2-11ea-a611-a01c8d23694a:1-2552456981
show slave status方式
Seconds_Behind_Master值
每个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间；备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值， 得到 seconds_behind_master。
主备延迟的主要来源是备库接收完 binlog 和执行完这个事务之间的时间差。
你可能会问，如果主备库机器的系统时间设置不一致，会不会导致主备延迟的值不准？ 其实不会的。因为，备库连接到主库的时候，会通过执行 SELECT UNIX_TIMESTAMP() 函数来获 得当前主库的系统时间。 如果这时候发现主库的系统时间与自己不一致，备库在执行 seconds_behind_master 计算的时候会自动扣掉这个差值。
显示参数Seconds_Behind_Master不为0，可以初步判断主从有延迟。
执行位点比较
Relay_Master_Log_File和Master_Log_File显示bin-log的编号相差很大， 说明bin-log在从库上没有及时同步，所以近期执行的bin-log和当前IO线程所读的bin-log相差很大。
Master_Log_File 和 Read_Master_Log_Pos，表示的是读到的主库的最新位点；
Relay_Master_Log_File 和 Exec_Master_Log_Pos，表示的是备库执行的最新位点。
Auto_Position=1 ，表示这对主备关系使用了 GTID 协议。也可根据Retrieved_Gtid_Set和Executed_Gtid_Set比较
Retrieved_Gtid_Set，是备库收到的所有日志的 GTID 集合；
Executed_Gtid_Set，是备库所有已经执行完成的 GTID 集合。
relay日志堆积量判断
MySQL的从库数据目录下存在大量mysql-relay-log日志，该日志同步完成之后就会被系统自动删除，存在大量日志，说明主从同步延迟很厉害。
主从延迟的常见情况
1、备库的压力大。
备库上的查询耗费了大量的 CPU 资源，影响了同步速度，造成主备延迟。
2、大事务这种情况很好理解。因为主库上必须等事务执行完成才会写入 binlog，再传给备库。所以，如果一个主库上的语句执行 10 分钟，那这个事务很可能就会导致从库延迟 10 分钟。
3、另一种典型的大事务场景，就是大表 DDL
