围剿慢SQL，工行MySQL研发管控和治理实践（附PPT）

Posted 2022-01-26 dbaplus社群

3、发布阶段

在发布时，我们会根据CheckList，对相关实现情况进行核对勾选，在确保所有指标都达标以后，才允许它进行正式发布。这样就能够在应用质量方面有较大的提升。

八、未来畅想

最后简单介绍一下我们对未来的畅想，也就是我们现在正在做的事情。

上文提到，我们一直在做“1-5-10”。但是目前还处于“1”稳步推进，“5”和“10”艰难实现的阶段。

针对一分钟定位我们发现，我们其实并没有那么多采集指标，所以对一些数据可以加大采集，比如常规数据：CPU、内存......等，目前对于中间件系统基础监控数据已经完成处理了，像网络、QPS、连接数等。

针对mysql数据库，其实它有一些性能指标可以进行高密度采集，也有一些影响数据库性能的要素指标需要进行低密度采集。这部分主要分为两类，第一类是像ps.threads这种可以高密度地处理的，同时show engine innodb status，这样我们可以快速发现到底用哪些死锁，或迅速了解某个事务处理的数据量，以及哪些线程在做哪些事情等。这些是我们要做高密度采集的事情。低密度采集也就是我们提到过的摘要信息的处理，每小时进行一次快照的数据分析，同时通过events_statements_history，对数据进行定时采集。

通过高密度采集，我们可以快速进行一分钟定位，查出出现问题的具体位置。

接下来是五分钟预判。我们工行的实验室之前有用“逻辑回归加孤立森林算法进行异常检测，用图算法进行根因定位”对全链路进行一些根因的分析和追溯。但通过我们之前跟某Top企业交流时发现，根因定位这个方法实际的正确率只在40%左右，波动检测精度可达到80以上，但该算法属于监督算法，需要针对性训练，无法大规模普及，且模型并没有达到我们所预想的标准。之前阿里在中台有一篇宣传文章，介绍说它的五分钟预判准确率可以达到90%，虽然我不太相信这个值，但他们的模型应该是相对比较好的。

十分钟自愈这部分算是我们对未来的期望，我们希望未来在发现问题以后，系统可以直接自行处理。这部分其实我们现在在做的一些自动化运维可以达到这个要求。比如当数据库发现问题以后，经过一些检测，自动进行主从切换。这其实也属于十分钟自愈的范畴。

我们只能说还在路上，但是未来具体是什么样的？目前我们也只能猜测。希望未来会更加美好！

↓点这里可下载本文PPT，提取码：dpmy