江苏龙网

  1. 主页 > 生活百科 > >

MySQL慢查询风险指数模型设计

mysql

作者介绍
钱芳园 ， 专注数据库和数据库自动化领域的工程师 ， 擅长MySQL、redis运维以及基于Go语言的数据库自动化开发 。
 
一、背景
 
所谓 MySQL 慢查询 ， 是指在 MySQL 中执行时间超过指定阈值的语句将被记录到慢查询文件中 ， 它是我们 DBA 经常讨论的话题 。
 
但在慢查询方面 ， 做得更多的工作 ， 基本都是集中做一个慢查询平台 ， 可以很好的把慢查询收集起来 ， 然后管理起来 ， 方便查看各种信息 ， 方便和开发沟通 ， 方便看慢查询的发展趋势等等 。但这些工作 ， 对于解决慢查询来讲 ， 作用比较小 ， 因为久而久之 ， 当我们成功地把慢查询平台变为慢查询海洋时 ， 不管是开发 ， 还是 DBA  ， 都不知道我应该要去解决哪个慢查询了 ， 再加上 ， 解决一个慢查询 ， 本身其周期非常长 ， 比如涉及到发现慢查询、分析并优化慢查询、测试优化效果、修改业务代码、发布上线以及观察效果等等 。这么长的流程 ， 这么长的周期 ， 很明显给我们解决慢查询造成了非常大的阻力 。
 
慢查询太多 ， 对于业务而言 ， 是有很大风险的 ， 可能随时都会因为某种原因而被触发 ， 并且根据我们的经验 ， 数据库最常出现的问题 ， 都是因为慢查询导致数据库慢了 ， 进而导致整个实例雪崩 ， 从而导致了线上故障 。
 
从另外一个角度来考虑 ， 解决慢查询 ， 是业务和 DBA 双方面的问题 ， 但通常情况下 ， 业务并不关心自己使用的数据库是不是有慢查询 ， 只关心数据库是不是能返回正确的数据 ， 对数据库造成什么影响 ， 并不太关注 。而这个时候 ，  DBA 只能去“被动接受” ， 并且只能是在问题出现之后 ， 再去讨论解决相应的问题 。
 
可能有人会问 ， 有慢查询 ， 难道 DBA 不知道吗？为什么不提前解决 ， 非要等到出了问题才解决 ， 这个问题 ， 就是本文今天的主题 ， 我们如何把被动解决 ， 变为主动 。
 
二、分析
 
根据上面的背景讲述 ， 我们其实知道 ， 为什么不能提前把问题发现并解决呢？主要原因是 ，  DBA 面对慢查询的海洋时 ， 并不能有效地知道 ， 每个慢查询对业务影响的严重程度 ， 再加上解决慢查询的周期很长 ， 可能针对一个慢查询 ， 从开始到解决完成 ， 需要跟踪半个月都不止 ， 从而造成了慢查询的被动解决 ， 成为 DBA 内心的痛 。
 
所以 ， 其实最根本的原因是慢查询太多 ， 同时慢查询没有明确的优先级 ， 不知道我们最先应该要解决哪个慢查询 ， 业务同学也是不知道的 。虽然有平台可查 ， 但他们在面对大量的慢查询时 ， 解决的意愿就不是太高 ， 最终慢查询也越积来越多 ， 直到最后影响业务运行 。
 
所以 ， 最有效的解决办法就是 ， 需要建立一种评分机制 ， 将当前慢查询系统中的慢查询进行评分 ， 按照分数给出优先级 ， 然后根据优先级 ， 将慢查询信息推送给对应的业务方 ， 要求他优先解决可能会对线上产生严重问题的慢查询 ， 再逐步解决次优先级的慢查询 ， 以此类推 。
 
三、解决思路
 
通过建立一套评分的模型 ， 给定任何一个慢查询 ， 根据慢查询的关键属性 ， 计算出分数 。假定总分数为100 ， 分数越高则风险指数越高 。
 
评分模型可以简单描述为：
 
score=func(x) 
四、设计模型
 
1、选取评分项
 
慢查询主要因素是由查询次数( QueryCount )和查询其他各项指标(例如锁等待时间、扫描行数、查询时间、发送数据等)组成 。
 
2、查询次数
【MySQL慢查询风险指数模型设计】 


推荐阅读


上一篇：琅琊仙草明日叶,明日叶健康料理

下一篇：月经期适合喝什么茶,女生适合喝什么茶