从库seconds_Behind_Master延迟总结

一.第一类：

这类延迟可能造成服务器由较高的负载，可能是CPU/IO的负载。因为从库在实际执行event，如果我们服务器的负载比较高一个考虑这几个情况：

1.大事物造成的延迟，其延迟不会从0开始增加，而是直接从主库执行了多久开始。

2.大表DDL操作的延迟，其延迟会从0开始，因为query_event记录了准确的执行时间

3.表没有合理的使用主键或者唯一键造成的延迟，这种情况不要以为设置slave_rows_search_algorithms参数为index_scan,hash_scan就可以完全解决

4.参数sync_relay_log,sync_master_info,sync_relay_log_info不合理导致，特别是sync_relay_log会极大影响从库的性能。

5.从库开启log_slave_update参数开启

 

二。这一些延迟往往不会造成服务器由较高的负载，他们要么没有实际的执行event，那么就是做了特殊的操作：

1.长期未提交的事物可能造成延迟瞬间增加，因为GTID_EVENT和XID_EVENT是提交时间

2.innodb层的行锁操作的延迟，这个是从库由修改操作并且和SQL线程修改的数据由冲突的情况下造成

3.MySQL层的DML LOCk造成的延迟

4.MTS中不合理的参数设置slave_checkpoint_period参数导致

5.在从库运行期间手动改大了从库服务器时间