主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。
- 备库所在机器的性能要比主库所在的机器性能差。这种部署现在比较少了。因为主备可能发生切换，备库随时可能变成主库，所以主备库选 用相同规格的机器，并且做对称部署，是现在比较常见的情况。
- 备库的压力大。一般的想法是，主库既然提供了写能力，那么备 库可以提供一些读能力。或者一些运营后台需要的分析语句，不能影响正常业务，所以只能在备库上跑。
- 大事务。因为主库上必须等事务执行完成才会写入 binlog，再传给备库。所 以，如果一个主库上的语句执行 10 分钟，那这个事务很可能就会导致从库延迟 10 分钟。所以不要一次性删除大量数据。
- 备库没有并行复制能力。下面是其解决方法。
把上图中只有一个线程的 sql_thread，拆成多个线程。
coordinator 就是原来的 sql_thread, 不过现在它不再直接更新数据了，只负责读取中 转日志和分发事务。真正更新日志的，变成了 worker 线程。而 work 线程的个数，就是由参数 slave_parallel_workers 决定的。把这个值设置为 8~16 之间最好（32 核物理 机的情况），毕竟备库还有可能要提供读查询，不能把 CPU 都吃光了。