写点什么

慢 SQL 治理实践及落地成果分享 | 京东物流技术团队

  • 2023-09-19
    北京
  • 本文字数:2193 字

    阅读完需:约 7 分钟

慢SQL治理实践及落地成果分享 | 京东物流技术团队

一、治理背景

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

发布于: 刚刚阅读数: 2
用户头像

拥抱技术,与开发者携手创造未来! 2018-11-20 加入

我们将持续为人工智能、大数据、云计算、物联网等相关领域的开发者,提供技术干货、行业技术内容、技术落地实践等文章内容。京东云开发者社区官方网站【https://developer.jdcloud.com/】,欢迎大家来玩

评论

发布
暂无评论
慢SQL治理实践及落地成果分享 | 京东物流技术团队_数据库_京东科技开发者_InfoQ写作社区