提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档
目录
1.2 从库负载较高(CPU负载高、IO负载高、网络负载高)
提示:以下是本篇文章正文内容,下面案例可供参考
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 引入其他的存储
分布式缓存,短时间内不失为一个绝佳的方案,读写快
总结
每天进步一点点!