一、治理背景

数据库系统性能问题会对应用程序的性能和用户体验产生负面影响。慢查问可能导致应用程序响应变慢、申请沉积、零碎负载减少等问题，甚至引发零碎解体或不可用的状况。慢SQL治理是在数据库系统中针对执行迟缓的SQL查问进行优化和改良的一项重要工作。

但原有的治理节奏，个别在大促备战期间，集中投入人力紧急治理，日常对慢SQL的关注度不高；即便研发团队想着手治理，实例下的SQL明细筛选繁琐，趋势不明，短少系统化，数字化的治理计划。

所以为了保证系统稳定性，预防潜在慢SQL导致应急事变，发动慢SQL常态化备战专项，下文次要形容专项的实际及落地状况。

二、阶段布局

1.0阶段

指标：【造成常态化治理机制，关注慢SQL解决的有效率】

扭转慢SQL治理习惯，由原大促备战期间治理，落地依照日维度产生的慢SQL每天跟进，关注双周维度治理的有效率。

关注指标：

逾期率 = 工单逾期数量（创立工夫在当季度的工作）/总量（创立工夫在当季度的工作） 注：超过14天未解决实现的算逾期，逾期与否以第一次实现的工夫来判断，如果在截止日期前未实现，算逾期；如果在截止日期前实现，然而重开后，在截止日期后实现，不算逾期，算重开；挂起的如果超过14天会统计到逾期里；

重开率 =工单重开次数（创立工夫在当季度的工作，如果是一个工作被重开5次，记录为5）/总量（创立工夫在当季度的工作）

2.0阶段

指标：【彻底根治慢SQL历史债，达成阶段性内的>0.9s清零】

通过1.0阶段研发团队有序进行慢SQL的逐渐治理，后期曾经无效解决局部慢SQL数据，但仍存在历史债，影响零碎稳定性。2.0阶段要求双周阶段性清零。

关注指标：

P0工单推送数=大于0.9s推送工夫在当周的工作总数 注：申明级别划分，

P0 执行工夫大于0.9秒，且达到阈值10次

P1 执行工夫大于0.9秒，但未达到阈值10次

P2 执行工夫小于0.9秒未加索引，且达到阈值10次

P3 执行工夫小于0.9秒未加索引，但未达到阈值10次

P0工单存量数=大于0.9s推送工夫在当周的工作中状态是非已解决的总数

解决率=大于0.9s推送工夫在当中的工作状态是已解决的/推送工夫在当周的工作总数

3.0阶段

指标：【进步零碎性能指标，阶梯型升高慢SQL阈值】

存在较大隐患的0.9s阶段性清零后，对慢SQL工单逐渐精细化，依照阶梯维度逐渐升高慢SQL定义阈值，依照双周维度对新增慢SQL清零。

关注指标：

P0工单推送数=大于0.9s推送工夫在当周的工作总数 注：申明级别划分，

P0 执行工夫大于0.9秒

P1 执行工夫小于等于0.9秒大于0.7秒

P2 执行工夫小于等于0.7秒大于0.5秒

P3 执行工夫小于等于0.5秒未加索引

P1工单推送数=小于等于0.9s大于0.7s推送工夫在当周的工作总数

P2工单推送数=小于等于0.7s大于0.5s推送工夫在当周的工作总数

存量数=推送工夫在当周的工作中状态是非已解决的总数

解决率=推送工夫在当中的工作状态是已解决的/推送工夫在当周的工作总数

4.0阶段

指标：【前置预防慢SQL，落地数据库操作标准】

预期指标，彻底解决历史债晋升零碎性能指标后，贯彻数据库操作标准预防新增慢SQL，后续继续关注新增的慢SQL，管制新增数量指标周清。

关注指标：

工单新增数=推送工夫在当周的非现存指纹ID的工作总数

存量数=推送工夫在当周的工作中状态是非已解决的总数

解决率=推送工夫在当中的工作状态是已解决的/推送工夫在当周的工作总数

三、落地计划

①数据筹备

阈值定义

联合二级部门业务，每天收集SQL的查问工夫是T-1天，执行工夫>0.9秒或<0.9秒但执行打算内未走索引的，剔除bi_cx和wlcx抽数后（不辨别主从），聚合雷同指纹慢SQL均辨认为现存危险慢SQL。

明确等级

不同治理阶段，会针对慢SQL划分优先级，按P0-P3程序，推动研发由高到低依照不同解决时效进行考核。同时提供辅助诊断信息，包含触发该慢SQL治理工作的数据库IP/域名/库名/执行耗时/执行打算等。

归类筛选

依照实例信息，数据库名，归属零碎，归属产品条线，查问工夫，聚合指纹等进行归类，不便归类出慢SQL的同一问题源。

②工单推动

工单流转

依照业务条线划分，明确每个条线工单接口人，对立下派慢SQL工单给到接口人，由接口人依照零碎散发组内同学，逐个解决。

解决思路

借鉴dba等提供的解决思路，同时总结团队内落地的解决方案，推动慢SQL疾速解决。

③趋势剖析

图表制作

依据每个阶段关注指标数据，制作慢SQL解决趋势图表，实现团队内可清晰查看，每个实例下的慢SQL明细，反对多个维度筛选；同时依照工夫维度反对查看解决趋势了，现存数量等。

通晒复盘

以专项周会的模式，同步研发团队解决节奏和进度，保障继续推动。

④过程跟踪

1.0阶段次要关注解决有效性

2.0阶段关注>0.9s的治理，进行历史债的清理

P0级SQL的解决跟进：

现有历史债的清零：

按月度呈现慢SQL量的趋势

四、落地后果

【零碎保障】

通过慢SQL的逐渐治理，截止529封板前，团队累计解决慢SQL831条，实现往年618备战期间，阶段性内的历史债清零。日常实现慢sql治理索引增加和代码优化，大促重点关注疑难和剖析未应用索引，做到备战无脱漏。

更是间接保障了零碎的稳定性，近半年无因慢SQL导致的线上问题。

【计划积淀】

随着慢SQL治理作为专项融入到研发的日常工作，首先团队内为防止新的慢SQL产生，落地数据库开发标准，京东团体数据库开发标准-V1.0-公示稿，同时如何剖析SQL、疾速定位、高效解决，团队内也输入了治理的解决方案。

五、总结

通过专项各个阶段的推动落地，团队内贯彻了治理指标，积淀了解决方案，后续慢SQL治理会继续化推动，从而保障系统稳定性。

作者：京东物流 刘红妍
起源：京东云开发者社区 自猿其说 Tech 转载请注明起源