互联网场景一般读请求次数远大于写请求。笔者所在的公司，跨境电商场景，读写比高达100:1 ！所以在业务量上涨之后，读写分离是一个很好的性能优化方案。
那么问题来了， 一旦启动读写分离的方案，从库的延迟变得极为敏感。
首先介绍下 MySQL主从复制的原理：
主库上有个 dump线程，从库上有 slave io 和 slave sql 线程 ，
简单来说， dump线程负责将 生成的binlog发送给从库，slave io 线程负责将binlog 落地为relaylog，slave sql线程负责解析relaylog并应用到从库中
MySQL从库延迟本质原因是逻辑复制，binlog是逻辑日志，应用sql肯定要花费时间
整条链路上任何一个环节都有可能导致从库延迟。通常有哪些场景会导致MySQL主从延迟呢？
1、网络
binlog通过网络从主库传输到从库，如果网络发生抖动，或者带宽打满，必然会影响从库复制
2、机器配置
有时候因为资源限制，从库可能会使用低配机器，cpu/磁盘不给力，导致从库应用sql变慢，产生复制延迟。所以强烈建议，主从数据库配置保持一致。
3、负载
很多时候，会将从库提供给BI/大数据侧使用，ap型复杂sql导致从库负载高，slave sql thread执行缓慢，产生复制延迟。所以要提供专用从库给BI/大数据，并且声明数据非实时（准实时）
4、锁
从库在备份的时候，为获取一致性位点信息，执行FTWRL (flush tables with read lock) 生成一个全局读锁。如果FTWRL 被阻塞，后续涉及到该表的会话都会被阻塞，包括 slave sql thread；
此外 ，从库在执行ddl时被 长事务/长sql阻塞，无法获取mdl锁，也会导致复制延迟。 所以在从库执行备份时，要关注会话状态
5、大表DDL
直接在主库上 对 大表执行DDL操作，主库需要多长时间，从库就需要多长时间。例如：主库某表加个字段需要1min，那么从库执行ddl也需要1min， 那么在这1min之内，从库就处于延迟状态。
所以针对大表ddl， DBA会使用一些工具来完成，而不是直接在主库上执行
6、大事务
一个大事务，比如修改了大量数据，花费了N秒，那么同样的，在从库上也需要执行N秒。所以强烈建议将大事务拆成小事务，单个事务修改不超过2000行。
7、长事务
长事务未必是大事务，是指事务中的sql执行间隔比较长
Seconds_Behind_Master计算逻辑 ：从库执行时间点-主库执行时间点- △z主从时间差
长事务会导致Seconds_Behind_Master值出现抖动，飚的很高，很快恢复
8、性能参数
sync_binlog、innodb_flush_log_at_trx_commit、innodb_io_capacity等刷盘性能参数，影响从库的io性能，可适当调整
9、并行复制
MySQL从5.7开始，引入行级别并行复制，相继经历 commit order、logic clock、write set 方式，一般情况下，并行线程数slave_parallel_workers设为 8或16 达到最大性能。
