MySQL主从复制延迟的原因及解决办法
简介
检查延迟的方法：在从库上通过SHOW SLAVE STATUS检查Seconds_Behind_Master值即可获取主从复制延迟的秒数。
主从复制延迟，可能的原因有主库和从库方面：
① 主库写binlog不及时。
② dump线程压力大
③ IO线程阻塞
④ 表缺乏主键或唯一索引（常见）
假设主库更新一张500w表中的20w行数据，该update语句仅需要全表扫描1次；而在row格式下，记录到binlog日志中的SQL为20w次update操作，此时SQL Thread重放将特别慢，因为每一次update都需要进行一次全表扫描，即从库需要执行20w次的全表扫描。
⑤ 主库DML请求频繁（tps较大）
⑥ 主库执行大事务,导致从库SQL慢
⑦ 主库对大表执行DDL语句
⑧ 主库与从库硬件配置不一致
⑨ 从库自身压力过大
⑩ MyISAM存储引擎
⑪ 主从复制的服务器时钟是否一致。主从同步延迟与系统时间的关系，查看主从两台机器间系统时间差
⑫ 网络通信是否存在延时。主从同步延迟与压力、网络、机器性能的关系，查看从库的IO，cpu，mem及网络压力
⑬ 从库查询是否优化（比如存在查询慢，导致从库性能差，处理不过来）
⑭ 是否启用了延迟复制，使用“show slave status”查看SQL_Delay是否大于0
一般情况下，复制延迟大概率是从库的 sql thread 应用 relay log 慢导致的，很少是因为 io thread 慢导致的。io thread 慢的话是一些故障导致的，是罕见的，可能磁盘慢或者网络慢导致。
下面是常见的 sql thread 应用复制延迟发生的原因和解决办法。
sql thread 应用复制延迟发生的原因和解决办法
1. 主从服务器的配置或者压力不一，从实例的IO能力太弱
这个需要技术管理手段去规避，务必要保证主备库无论从硬件配置、操作系统配置、mysqld 配置都要一致，不会出现主库比备库性能好很多的情况。不建议备库开读写分离，有财力的公司读写分离的读可以放在另外的只读从库上。
2. 主库的TPS太高
在 MySQL5.5 及之前版本，从库是不支持并行复制功能的，主库上会有并发事务，利用多核 CPU，多个连接同时写入数据，但从库 sql thread 线程应用 relay log 时不支持并行回放，只能单线程回放，那么主库只要并发高的时候，从库永远是复制延迟的。
MySQL5.6 版本优化了这个问题，从库只支持基于 database 的并行复制，也就是如果主库上多个并发事务必须在不同 database 上跑，在从库上才能并行复制，这就非常鸡肋，大多数业务的并发 SQL 都在同一个业务库的，所以这并不能并行复制，这个问题是 MySQL5.6 复制延迟的常见原因，请务必升级到 MySQL5.7 以支持基于逻辑时钟的并行复制。
MySQL5.7 版本的基于逻辑时钟的并行复制，是基于组提交的原理来实现的，首先在主库满足能组提交的事务，都是可以并行回放，因为这些事务都已进入到事务的 prepare 阶段，则说明事务之间没有任何冲突（否则就不可能提交）。但他没有完全模拟主库上的并发执行，所以在从库上的回放力度依然没有主库高，但比 MySQL5.6 鸡肋的基于 database 的并行复制强多了，这个时候已经能消灭大多数复制延迟了。MySQL5.7.22 开始官方推出了基于 writeset 的并行复制，他能把并行复制推到了全新的高度，怎么说呢？就是主库原本不是并行的 SQL，只要不冲突在从库上都能并行，极限情况下，从库回放速度甚至比主库还高！这基本上是消灭了这个原因下的复制延迟。
并行复制是有相关参数推荐的，请视情况调整，如有疑问可以与我联系。
