慢SQL治理实践及落地成果分享

sql,治理,实践,落地,成果,分享 · 浏览次数 : 781

小编点评

## 慢SQL治理专项落实案例分析 **一、治理背景** 慢查询会导致数据库性能问题,降低用户体验,甚至引发系统崩溃或不可用的情况。为了防止慢SQL导致应急事故,发起慢SQL常态化备战专项,以提升系统稳定性。 **二、阶段规划** **1.0阶段目标:形成常态化治理机制,关注慢SQL解决的有效率** * 改变慢SQL治理习惯,由原大促备战期间治理,落地按照日维度产生的慢SQL每天跟进,关注双周维度治理的有效率。 * 关注指标:逾期率 = 工单逾期数量(创建时间在当季度的任务)/总量(创建时间在当季度的任务) **2.0阶段目标:彻底根治慢SQL历史债,达成阶段性内的>0.9s清零** * 经过1.0阶段研发团队有序进行慢SQL的逐步治理,前期已经有效解决部分慢SQL数据。 * 经过2.0阶段,针对历史债进行清理,以提升系统性能指标。 **3.0阶段目标:提高系统性能指标,阶梯型降低慢SQL阈值** * 存在较大隐患的0.9s阶段性清零后,对慢SQL工单逐步精细化,按照阶梯维度逐步降低慢SQL定义阈值。 * 按双周维度对新增慢SQL清零。 **4.0阶段目标:前置预防慢SQL,落地数据库操作规范** * 预期目标,彻底解决历史债提升系统性能指标后,贯彻数据库操作规范预防新增慢SQL,后续持续关注新增的慢SQL,控制新增数量目标周清。 **五、落地方案** 1. 数据准备阈值定义结合二级部门业务,每天搜集SQL的查询时间是T-1天,执行时间>0.9秒或<0.9秒的慢SQL均被识别为现存风险慢SQL。 2. 工单推进工单流转按照业务条线划分,明确每个条线的工单接口人,统一下派慢SQL工单给到接口人,由接口人按照系统分发组内同学,逐一解决。 3. 解决思路借鉴dba等提供的解决思路,同时总结团队内落地的解决方案,推进慢SQL快速解决。 4. 过程跟踪1.0阶段主要关注解决有效性,2.0阶段关注>0.9s的治理,进行历史债的清理P0级SQL的解决跟进。 5. 每天保障系统稳定性,近半年无因慢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 转载请注明来源

与慢SQL治理实践及落地成果分享相似的内容:

慢SQL治理实践及落地成果分享

为了保证系统稳定性,预防潜在慢SQL导致应急事故,发起慢SQL常态化备战专项,下文主要描述专项的实践及落地情况。

慢SQL的致胜法宝

大促备战,最大的隐患项之一就是慢SQL,对于服务平稳运行带来的破坏性最大,也是日常工作中经常带来整个应用抖动的最大隐患,在日常开发中如何避免出现慢SQL,出现了慢SQL应该按照什么思路去解决是我们必须要知道的。本文主要介绍对于慢SQL的排查、解决思路,通过一个个实际的例子深入分析总结,以便更快更准确

慢SQL原因分析之索引失效

现象 最近收到一个慢sql工单,慢sql大概是这样:“select xxx from tabel where type = 1”。 咦,type字段明明有索引啊,为啥是慢sql呢? 原因 通过执行explain,发现实际上数据库执行了全表扫描,从而被系统判定为慢sql。这时有一定开发经验的同事会说:

慢 SQL 优化之索引的作用是什么?

本文针对 MySQL 数据库的 InnoDB 存储引擎,介绍其中索引的实现以及索引在慢 SQL 优化中的作用。本文主要讨论不同场景下索引生效与失效的原因。

[转帖]PostgreSQL 慢查询SQL跟踪

https://www.cnblogs.com/VicLiu/p/12017704.html PostgreSQL 开启慢SQL捕获在排查问题时是个很有效的手段。根据慢SQL让我在工作中真正解决了实际问题,很有帮助。 PostgreSQL 日志支持的输出格式有 stderr(默认)、csvlog 、

教你处理数仓慢SQL常见定位问题

摘要:通常在运维监控出现CPU使用率较高、P80/P95指标较高、慢SQL数量上升等现象,或者业务出现超时报错时,优先应排查是否出现慢SQL。 本文分享自华为云社区《GaussDB慢SQL常见定位处理手段》,作者:酷哥。 关键指标 通常在运维监控出现CPU使用率较高、P80/P95指标较高、慢SQL

Mybatis-SQL分析组件

大促备战,最大的隐患项之一就是慢sql,带来的破坏性最大,也是日常工作中经常带来整个应用抖动的最大隐患,而且对sql好坏的评估有一定的技术要求,有一些缺乏经验或者因为不够仔细造成一个坏的sql成功走到了线上,等发现的时候要么是造成了线上影响、报警、或者后置的慢sql采集发现,这时候一般无法快速止损,需要修改代码上线、或者调整数据库索引。

一文带你搞懂如何优化慢SQL

最近通过SGM监控发现有两个SQL的执行时间占该任务总执行时间的90%,通过对该SQL进行分析和优化的过程中,又重新对SQL语句的执行顺序和SQL语句的执行计划进行了系统性的学习,整理的相关学习和总结如下;

[转帖]show processlist中kill锁表语句与慢sql

https://blog.51cto.com/u_11310506/2071463 show processlist中kill锁表语句与慢sql 1 单个kill mysql> show processlist; mysql > kill 251; #批量kill 1)查找Lockd语句 mysql

高性能MySQL实战(三):性能优化 | 京东物流技术团队

这篇主要介绍对慢 SQL 优化的一些手段,而在讲解具体的优化措施之前,我想先对 EXPLAIN 进行介绍,它是我们在分析查询时必要的操作,理解了它输出结果的内容更有利于我们优化 SQL。为了方便大家的阅读,在下文中规定类似 key1 的表示二级索引,key_part1 表示联合索引的第一部分,uni