最近碰到几次MySQL主从延时的问题，也有同行在抱怨这个，稍微整理一下
------------------------------------正文------------------------------------
出现问题的两个场景：
场景1.主库进行alter操作，花费大约10min，从库复现这个alter的时候，也花费了约10min的时间，期间延时不断在增加；
场景2.主库上对一张MyISAM的表有大量的增删改操作，从库的业务语句在操作这张表经常会遇到表锁，导致从库延时；
场景问题分析：
场景1：其实这个场景很简单，这种需要花费很多时间的alter语句，在主库花费这么久，在从库复现必然也是要花费很多时间的，自然会阻塞之后的同步；
场景2：
首先要确认MyISAM的特性，MyISAM的表是表级别的锁，读写互斥，
当同步的SQL线程在增删改数据的时候，如果有select语句在操作这个表，是会产生表级锁，阻塞同步的SQL线程，简单模拟以下表级锁阻塞从库SQL线程的情况
MyISAM的表遇到这种情况其实和情景1是一种类型的，那就是主库上的操作在从库复现的时候很慢/被阻塞，出现问题的地方都是复现的SQL本身，这种类型的问题，基本只能把这些“问题SQL”放在空闲时段去操作，属于DBA的操作规范一类了，如果是正常时间段出现了这种情况，可以考虑单独分离某一台延时的从库，屏蔽业务请求，等延时消除以后，再添加回去，再替换另外有延时的从库，依次去追主库了；
主从延时还存在一种类型，就是从库的同步卡在写binlog这一部分，典型的表现就是从库的系统IO等待很高，这种情况，视业务类型去修改事务组和日志刷新策略的值，或者更换存储，提高硬件能力~