一、治理背景
数据库系统性能问题会对应用程序的性能和用户体验产生负面影响。慢查询可能导致应用程序响应变慢、请求堆积、系统负载增加等问题，甚至引发系统崩溃或不可用的情况。慢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 转载请注明来源
