Master_Log_File IO线程延迟，并不是Relay_Master_Log_File SQL线程延迟，可能的原因如下：
1.由于sync_relay_log值过低，导致Slave频繁刷新relay_log文件，使 Slave的硬盘资源消耗过高，所以导致SlaveIO Thread很慢。
2.Master/Slave压力过大导致Slave IO Thread不能及时响应， 无法及时获得Master的event。
3.网络丢包严重。小包可以连接并且保持连接不断，但是大包就无法发送。可能是Master和Slave关于TCP MTU值设置不一致导致。
4.Master和Slave网络链接已经断开。但slave_net_timeout值等于0（表示完全禁用心跳）或者slave_net_timeout和Slave_heartbeat_period非常大（表示检测主从心跳的时间）。
5.Master的binlog非常大，io线程的file很长时间都在读同一个。
数据更新的执行流程：
1、执行器先从引擎中找数据，如果在内存中直接返回，如果不在内存中，查询后返回
2、执行器拿到数据之后会先修改数据，然后调用引擎接口重新写入数据
3、引擎将数据更新到内存，同时写数据到redo中，此时处于prepare阶段，并通知执行器执行完成，随时可以操作
4、执行器生成这个操作的binlog
5、执行器调用引擎的事务提交接口，引擎把刚刚写完的redo改为commit状态，更新完成
redo的两阶段提交
先写redo log后写binlog：假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启，由于redo log写完之后，系统即会崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值为1.但是由于binlog没有写完就crash了，这时候binlog里面没有记录这条语句，因此之后备份的时候，binlog中没有这条语句。然后会发现如果需要用该备份恢复数据库时，由于binlog会丢失一次更新，恢复出来这一行的值就是0，与原库的值不同
先写binlog后写redo log：如果binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0.但是binlog里面已经记录了“把c从0改为1”这个日志。所以在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库不同。
1、主从延迟产生的原因有哪些？
在某些部署环境中，备库所在的机器性能要比主库所在的机器性能差，此时如果机器性能的资源不足就会影响备库同步的效率。
备库充当了读库，一般情况下主要写的压力在于主库，那么备库会提供一部分读的压力，而如果备库的查询压力过大的话，备库的查询消耗了大量的CPU资源，那么必不可少的就会影响同步的速度。
大事务执行，如果主库的一个事务执行了10分钟，而binlog的写入必须要等待事务完成之后，才会传入备库，那么此时在开始执行的时候就已经延迟了10分钟了。
主库的写操作是顺序写binlog，从库单线程去主库顺序读binlog，从库取到binlog到本地执行。mysql的主从复制都是单线程的操作，但是由于主库是顺序写，所以效率很高，而从库也是顺序读取主库的日志，此时的效率也是比较高的，但是当数据拉取回来之后变成了随机的操作，而不是顺序的，所以此时成本会提高。
从库在同步数据的同时，可能跟其他查询的线程发生锁抢占的情况，此时也会发生延时。
当主库的TPS并发非常高的时候，产生的DDL数量超过了一个线程所能承受的范围的时候，你、那么也可能带来延迟。
在进行binlog日志传输的时候，如果网络带宽不是很好，网络延迟也可能会造成数据同步延迟。