常见原因以及解决方案:
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语句时由于效率不佳的执 行计划导致执行速度变慢,从而产生数据延迟。
解决方案:重新收集表的统计信息