一、主从复制延迟
情况1：（https://blog.csdn.net/u010522235/article/details/51865978）
主库的DDL(alter、drop、repair、create)导致只读节点延迟
可能1：只读节点与主库的DDL同步是串行进行的，如果DDL操作在主库执行时间很长，那么同样在备库也会消耗同样的时间，比如在主库对一张500W的表添加一个字段耗费了10分钟，那么在只读节点上也同样会耗费10分钟，所以只读节点会延迟600S，其他常见操作比如：
mysql> alter table test add column nn varchar(10);
mysql> alter table test add index(jj);
可能2：只读节点上有一个执行时间非常长的的查询正在执行，那么这个查询会堵塞来自主库的DDL，读节点表被锁，直到查询结束为止，进而导致了只读节点的数据延迟。在只读节点上可以通过执行show processlist命令查看连接的状态处于: Waiting for table metadata lock
解决办法：
对于可能1，只能说执行操作之前对可能带来的影响要有考量，对于情况2，可以kill掉只读节点上的大查询进行，就可以恢复只读节点与主节点的数据同步
对于二进制日志，由于其写入时间发生在事务提交时，因此假设产生了1G的二进制日志，则需要事务提交时间会包含这1G日志的写入时间。在Oracle中有一种说法，事务的提交速度都是平的，不论事务的大小。这在MySQL数据库中是不成立的。即，MySQL的提交速度取决于事务产生的二进制日志的大小，事务提交的速度不是平的。
更为糟糕的是，MySQL主从复制在大事务下的延迟。同样假设1个大事务在主服务器上执行了1个小时，则需要在最后的提交时间传送到从服务器。主从延迟的时间至少为1个小时，若从服务器执行还需1个小时，则主从复制延迟的最坏情况可能是2个小时。物理复制则不存在这样的限制，原因还是如前所述，事务提交过程中，日志已经在传输和回放。
一言以蔽之，对于MySQL数据库来说，任何时刻不允许有大事务执行。若要执行，则将大事务拆成一个个小的子事务来执行。这是最基本心法口诀，但却又和Oracle有着很大不同。总之，气宗、剑宗，本无好坏，学会理解其中的差异，融会贯通方可达风清扬般的致臻境界。
若遵循基本的口诀，大事务拆小事务，则MySQL从服务器的I/O线程不会有特别大的延迟。然，SQL线程的延迟依然无法解决。
早期，在MySQL5.6中，引入了并发复制，这个并发复制是数据库级别的，这意味着一个SQL线程可以处理一个数据库的连续事务，而不用等待其它数据库完成。这个版本的并发复制，可以理解成一个数据库一个SQL线程。
MySQL 5.7推出了多线程从机复制机制（下简称MTS，Multi-Thread Slave，又称并行复制 parallel replication）。之前多次举例某公司的电商业务，在开启并行复制后，复制延迟从8小时下降为0，对于解决延迟问题立竿见影。
然而，目前MTS机制基于组提交实现，简单来说在主上是怎样并行执行的，从服务器上就怎么回放。这里存在一个可能，即若主服务器的并行度不够，则从机的并行机制效果就会大打折扣。
然而，若主服务器就是单线程或少量的线程并发执行，则目前的MTS机制还是会有延迟。MySQL 8.0最新的基于writeset的MTS才是最终的解决之道。即两个事务，只要更新的记录没有重叠（overlap），则在从机上就可并行执行，无需在一个组，即使主服务器单线程执行，从服务器依然可以并行回放。相信这是最完美的解决之道，MTS的最终形态
总结
MySQL 5.7推出的Enhanced Multi-Threaded Slave解决了困扰MySQL长达数十年的复制延迟问题，再次提醒一些无知的PostgreSQL用户，不要再停留在之前对于MySQL的印象，物理复制也不一定肯定比逻辑复制有优势，而MySQL 5.7的MTS已经完全可以解决延迟问题。
配置文件开启MTS:
# slave
slave-parallel-type=LOGICAL_CLOCK #基于组提交的并行复制方式
slave-parallel-workers=16 #并行复制测试 开启16个线程 效果最佳
master_info_repository=TABLE #开启MTS功能后，务必将参数master_info_repostitory设置为TABLE，这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升，资源的竞争也会变大。在之前 InnoSQL 的版本中，添加了参数来控制刷新master.info这个文件的频率，甚至可以不刷新这个文件。因为刷新这个文件是没有必要的，即根据master-info.log这个文件恢复本身就是不可靠的。在MySQL5.7中，推荐将master_info_repositor
y设置为TABLE，来减小这部分的开销
relay_log_info_repository=TABLE
relay_log_recovery=ON