这几天遇到MySQL因为业务侧不规范操作导致主从同步延时的问题比较多，便想着总结下MySQL主从延时的原因，以及如何避免一些可能造成主从同步延时问题的操作，以免踩坑。
1).硬件问题:在实际生产上，可能存在这种情况，主库的服务器硬件资源比从库好，例如CPU，内存，磁盘等等，从而导致在进行主从同步时，从库的性能跟不上主库。
2).同步机制:MySQL主库中写binlog的操作是顺序写的，磁盘的顺序读写速度是很快的，同样，从库的I/O线程操作日志的执行速度也很快，SQL线程用来进行数据重放，重放的过程是随机写盘的，磁盘的随机读写速度比顺序读写慢的多，某一时刻relay log里面的数据来不及放进从库，就会产生主从延迟的情况。另外，在MySQL5.5之前，主从复制是单线程的，虽然MySQL5.5之后，MySQL5.6,以及MySQL5.7等后续版本支持并行复制并做了一系列的改进优化，但是在某些时刻并行复制还是会退化为单线程复制，这个也是导致主从复制延时的原因之一。3).并发问题:当主库并发高时，主库不同事物可以并行执行，但是从库可能只能串行执行，等待上一个事物执行完成后才能执行下一个事物。
4).事物问题:当主库执行大事务时，例如大表DDL，一个事务操作很多行时，也会导致从库出现主备延时。5).锁表问题:有些生产环境可能会实行读写分离机制，此时，在主库上写，在从库上进行读，如果某一时刻从库因为查询产生了锁等待的情况，此时只有在当前的操作执行完成后才会进行下面的操作，也会产生主从延迟。主从同步延时问题如何解决呢，如果主从延时较小，一般情况下当主库处于空闲期从库能够自动追平，如果延迟较大，则需要进行人工处理。举几个例子吧:1).情景一:某张表无主键，索引，在主库上进行大批量的delete等操作，导致主从延时较大。这种情况出现的原因有两方面，一方面表的数据量较大且无主键或相应的索引时，进行delete操作时，会全表扫描寻找可以删除的记录逐条删除，性能较差，解决思路有两种，思路一，如果该表信息不是很重要，长期会有频繁的delete等操作，可以考虑跳过该表的主从同步。思路二，如果不能跳过，可以先停止主从同步的SQL线程，然后手动在从库给相应的表加上合适的主键或索引，后期寻找合适窗口期再给主库添加。
2).情景二:从库延时较大，且延时时间较长，主库的部分binlog日志还未被从库读取就已经被清除了，此时只能重做备库了。
如何预防主从延时问题的出现，可以从以下几方面进行预防:1).尽量保持主备库的硬件配置一致，甚至从库的服务器配置略高于主库。
4).当设置读写分离的时候，在有条件的情况下，设置多个从节点进行读负载均衡，避免单个从节点压力过大或者长期出现锁等待。5).避免大事务，大表ddl操作，建议将大事务拆分为多个小事务进行执行，另外，表在最开始设计的时候尽可能设计规范，避免后期修改代价太大。
原文作者：DBA修行之路；如有侵权，请联系管理员删除。
