MySQL：DBA看主从延迟

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

[1.1 主库更新频繁或主库有大事务](#1.1 主库更新频繁或主库有大事务)

[1.1.1 程序相关](#1.1.1 程序相关)

[1.1.2 变更相关](#1.1.2 变更相关)

[1.2 从库负载较高（CPU负载高、IO负载高、网络负载高）](#1.2 从库负载较高（CPU负载高、IO负载高、网络负载高）)

[2.1 化解大事务](#2.1 化解大事务)

[2.2 控制从库读](#2.2 控制从库读)

[2.3 控制主库写](#2.3 控制主库写)

[2.4 引入其他的存储](#2.4 引入其他的存储)

提示：以下是本篇文章正文内容，下面案例可供参考

1、从DBA的视角来看影响主从延迟因素

1.1.1.1 避免大事务方式做数据操作，把大事务拆分为小事务。

例如，我一个事务里要对10w行数据做变更，那么这就是一个典型的大事务，我们可以采取多批次分批处理的方式，将10w行数据的变更分到1000次小事务中，每个事务处理的变更数量就变成了100，加快了处理速度，减少了主从延迟。

1.1.1.2 过高的并发适当做流量限制

这个很好理解，频繁的写操作，代表的是频繁的IO资源使用

1.1.2.1 DML变更

单SQL扫描行数大于10w的不建议直接执行，需改为基于主键或选择性高的索引进行变更

1.1.2.2 DDL变更

存在延迟风险的，错峰执行，避免对业务造成长时间的影响

工具手动执行(工具可控制从库延迟时间和不锁表，对延迟和锁表敏感业务场景)

对延迟敏感的业务从库避免执行长的查询语句------慢SQL

例如复杂的嵌套查询语句，没走索引且数据量大的SQL

基于以上影响主从延迟的因素，我们不难总结有以下三个方面去减少主从延迟。主从延迟不能完全避免，只能尽可能的缩短，或者采取其他的策略去降低延迟带来的影响。

编写程序或者SQL的时候，需要注意

我司的SQL提交平台，会列出来影响扫描影响行数，帮助做决策。

这个就得从业务上去把控了

比如我们经常写一些跑批的定时任务，那么就得避开业务高峰期。

我们直接读库的操作，如果数据变化不是非常频繁，可以短暂的借助于分布式缓存进行一个缓冲过渡

管理系统经常要把各种数据关联到一起显示及过滤，在提升复杂度的同事，也可能会导致索引失效，扫描的行数急剧上升，可以寻求其他的替代方案，避免直接对数据库进行复杂嵌套查询。