主备延迟，可以通过
show slave status命令显示的seconds_behind_master看到。
该指标的计算方式，binlog 中的时间字段与当前系统时间的插值。同时会获得主库的连接时间，来保证两个机器的系统时间相同。导致主备延迟的原因？ 1.主备库的参数配置不同。 2.主库 DML 语句并发大。 3.备库机器配置比主库配置差。尽量相同配置，避免主备切换。 4.备库的压力大，所有读操作都在备库。一主多从；binlog 导出外部系统。 5.大事务导致 (delete 过多数据，大表 DDL 等) 6.表上无主键情况 (主库通过索引改数据，备库回访只能全表扫描) 7.备库在进行备份操作 8.备库的空间不足
主备延迟
主备库存在同步延迟。
可以在备库上执行 show slave status 命令，它的返回结果里面会显示 seconds_behind_master，用于表示当前备库延迟了多少秒。
seconds_behind_master 的计算方法是这样的：
- 每个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间；
- 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到 seconds_behind_master。
可以看到，其实 seconds_behind_master 这个参数计算的就是 T3-T1。我们可以用 seconds_behind_master 来作为主备延迟的值，这个值的时间精度是秒。
如果主备库机器的系统时间设置不一致，会不会导致主备延迟的值不准？ 其实不会的。因为，备库连接到主库的时候，会通过执行 SELECT UNIX_TIMESTAMP() 函数来获得当前主库的系统时间。如果这时候发现主库的系统时间与自己不一致，备库在执行 seconds_behind_master 计算的时候会自动扣掉这个差值。
主备延迟的原因
情况一，备库所在机器的性能比主库所在的机器性能差。解决办法，相同配置机器，以避免需要主备切换的情况。
情况二，备库的压力大。有可能多读少写的场景，读操作都在备库进行，导致备库压力很大。解决办法，一主多从；将 binlog 输出到外部系统，如 Hadoop，让外部系统支持查询能力。
情况三，大事务导致主备延迟。有可能主库执行大事务 10 分钟，那么备库就会有 10 分钟的延迟，比如当 delete 语句删除太多数据时。另一种情况就是，大表的 DDL 操作，参考 问题定位：为什么表删除删一半，表文件大小不变？。
情况四，备库的并行复制能力。
情况五，从库上进行备份操作。
情况六，表上无主键的情况(主库利用索引更改数据,备库回放只能用全表扫描,这种情况可以调整 slave_ rows_search_algorithms 参数适当优化下)
情况七，备库空间不足的情况。
情况八，主库 DML 语句并发大,从库 qps 高。