提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
目录
1、从DBA的视角来看影响主从延迟因素
1.1 主库更新频繁或主库有大事务
1.1.1 程序相关
1.1.2 变更相关
1.2 从库负载较高（CPU负载高、IO负载高、网络负载高）
2、主从延迟的应对策略
2.1 化解大事务
2.2 控制从库读
2.3 控制主库写
2.4 引入其他的存储
总结
提示：以下是本篇文章正文内容，下面案例可供参考
1、从DBA的视角来看影响主从延迟因素
1.1 主库更新频繁或主库有大事务
1.1.1 程序相关
1.1.1.1 避免大事务方式做数据操作，把大事务拆分为小事务。
例如，我一个事务里要对10w行数据做变更，那么这就是一个典型的大事务，我们可以采取多批次分批处理的方式，将10w行数据的变更分到1000次小事务中，每个事务处理的变更数量就变成了100，加快了处理速度，减少了主从延迟。
1.1.1.2 过高的并发适当做流量限制
这个很好理解，频繁的写操作，代表的是频繁的IO资源使用
1.1.2 变更相关
1.1.2.1 DML变更
单SQL扫描行数大于10w的不建议直接执行，需改为基于主键或选择性高的索引进行变更
1.1.2.2 DDL变更
存在延迟风险的，错峰执行，避免对业务造成长时间的影响
工具手动执行(工具可控制从库延迟时间和不锁表，对延迟和锁表敏感业务场景)
1.2 从库负载较高（CPU负载高、IO负载高、网络负载高）
对延迟敏感的业务从库避免执行长的查询语句——慢SQL
例如复杂的嵌套查询语句，没走索引且数据量大的SQL
2、主从延迟的应对策略
基于以上影响主从延迟的因素，我们不难总结有以下三个方面去减少主从延迟。主从延迟不能完全避免，只能尽可能的缩短，或者采取其他的策略去降低延迟带来的影响。
2.1 化解大事务
编写程序或者SQL的时候，需要注意
我司的SQL提交平台，会列出来影响扫描影响行数，帮助做决策。
2.2 控制从库读
这个就得从业务上去把控了
比如我们经常写一些跑批的定时任务，那么就得避开业务高峰期。
我们直接读库的操作，如果数据变化不是非常频繁，可以短暂的借助于分布式缓存进行一个缓冲过渡
管理系统经常要把各种数据关联到一起显示及过滤，在提升复杂度的同事，也可能会导致索引失效，扫描的行数急剧上升，可以寻求其他的替代方案，避免直接对数据库进行复杂嵌套查询。
2.3 控制主库写
2.4 引入其他的存储
分布式缓存，短时间内不失为一个绝佳的方案，读写快
总结
每天进步一点点！
