一、MySQL的主从同步是一个很成熟的架构
优点：
1.在从库可以执行查询工作(通常使用的方案读写分离)，降低主库压力;
2.在从库进行备份，避免备份期间影响主服务器服务;
3.当主库出现问题时，可以切换到从库。
但是一旦使用不当就会造成主从的同步出现不同程度的延迟。使从的只读功能或主库要切换到从库的情况下数据出现大量的断层。
二、MySQL主从延迟主要有以下几种原因
1.从库配置过低；
2.主库的TPS过高导致只读节点延迟
3.主库的DDL(alter、drop、repair、create)导致只读节点延迟
4.主库执行大事务导致延迟
5.无主键的表进行DML操作导致延迟
三、下面来看一个生产由于事物过大造成的延迟案例
环境：mysql5.7.21 GTID方式主从
服务器:从库cpu配置达到192核
1.延迟情况
2.解析对应时间点的日志，日志序号：1403
3.检查在延迟情况下打印出现出来的事物情况GTID:a44a1c8a-6434-11e8-9096-a8eeb2af58ab:598187900
之前遇到过在某个事物卡死现象，这里显示此事物并没有问题。
4.查询对应日志mysql-bin.001403中对应的大事物
发现对应日志中有事物大约在760M左右
5.查询对应日志中的具体动作，分别截图如下
发现其中的三张表都有可能性。下面分别过滤三张表的具体动作
5.1、表a_init.tsc_kliykx
5.2、表a_fnnd.tfc_yxxdy
事物时间与问题时间不对应
5.3、表a_fnnd.tfc_zyxh
事物时间与问题时间不对应
佐证：
通过错误日志对应时间点也可以发现对应位点也发生了问题
四.结论
结合1403号日志的分析，问题大致出现在5.1步骤中的大事物中。解决这个问题可以适当加大设置max_allowed_packet、slave_pending_jobs_size_max或者取消双一配置，这样也只能临时解决问题，如果不控制事物大小无法根本解决问题。
MySQL中有INSERT事物建议在代码层面尽量控制到最小。对于update、delete的情况还是建议走主键的批量操作来执行。
事物过大在从库应用的时候也只能做到单个线程来执行回放。切成小个事物就可能做到尽量应用mysql多线程的特性，使回放尽快完成，追平主库。
最后：在MySQL发生问题的时候，千万别忘记检查系统日志、MySQL本身的各种日志，能提高快速定位问题点，或者做到互相佐证的目的。
