mysql 主从同步延迟原因以及解决方式

   常见原因以及解决方案：

1、表无主键或者二级索引：

     原因： 若binlog 为row格式且表无主键或者二级索引，当对大表进行dml操作(update、insert、delete）,从库在对binlog日志应用时会根据主键或者二级索引检索需要更改的行，如对应的表无主键索引或者二级索引，就会产生大量的全表扫描降低了日志应用速度，从而产生数据延迟

    解决方案：为所有表创建主键，若表不能创建主键，建议在选择性高的列上创建二级索引

2、大事务：

     原因:当主实例执行大数据量的 DML 操作，大量的 binlog 日志传送到从库时，从库需要花费与主实例相同的时间来完成相应事务，进而导致从库出现数据延迟。

     解决方案:建议将大事务拆分为小事务，通过 where 条件限制每次要处理的数据量，有助于从库迅速完成事务的执行，从而避免出现从库数据的延迟。

3、ddl操作：

     原因：与大事务原理类似，若 DDL 操作在主实例的执行时间很长，在从库也会花费相同甚至更长时间来执行该操作，从而阻塞了 DDL 操作。

     解决方案:建议在业务低峰期执行 DDL 操作。若因灾备实例、只读实例的查询业务而阻塞了 DDL 操作，建议直接 KILL 掉引起阻塞的会话来恢复主从数据的同步。

4、实例主机配置太低:

     原因:只读实例、灾备实例的规格小于主实例且负载较高，会导致只读实例、灾备实例的数据延迟。

     解决方案:建议只读实例、灾备实例规格大于等于主实例，如果只读实例、灾备实例承载了大量的分析类业务导致实例负载过高，需将其实例规格升级至合适的配置或 者对其性能低效的 SQL 进行优化。

5、waiting for table metadata lock:

    原因:长事物运行，阻塞 DDL，继而阻塞所有同表的后续操作；未提交事物，阻塞 DDL，继而阻塞所有同表的后续操作。

     解决方案：建议对实际业务和实例进行诊断，排查慢查询等指标，来定位耗时的长事务

6、表统计信息缺失或者失效:

      原因：sql执行计划的产生依赖于统计信息，若表上统计信息缺失或者无效，优化器有可能产生低效率的执行计划，从库在解析binlog执行sql语句时由于效率不佳的执 行计划导致执行速度变慢，从而产生数据延迟。

     解决方案：重新收集表的统计信息