福利贴|妙手神医瑶池:寻根溯源,哪条SQL导致了性能异常?

本文涉及的产品
数据传输服务 DTS,数据迁移 small 3个月
推荐场景:
MySQL数据库上云
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
数据传输服务 DTS,数据同步 small 3个月
推荐场景:
数据库上云
简介: 一文详解「根因SQL分析」

导读


随着数字江湖的风云变幻,阿里云瑶池数据库不断深化「云原生+Serverless」应用,旨在让数据平台像“搭积木”一样便捷轻巧,提供秒级弹性、开箱即用免运维等服务,打造智能化的一站式数据管理平台


书接上回,这边刚刚处理完寒霜城数据库存储空间急症,琅风山数据库的DAS生命监测系统就发出“性能指标异常”的警报(阿里云瑶池旗下的数据库自治服务DAS是基于机器学习和专家经验实现数据库自感知、自修复、自优化、自运维及自安全的云服务,为数据库提供7*24h的“生命异常监测”)妙手神医瑶池在一阵急促的鹤唳声中腾云离开,火速奔赴数据纷争中心。



第 1 回|慢SQL夜袭数据库,妙手神医瑶池诊疗心法大公开

第 2 回|妙手神医瑶池诊疗实录:数据库存储空间去哪儿了?



1. 异常SQL搅动风云,精准诊疗化险为夷


远远望去,烽烟缭绕,琅风山数据库的警报声在山间回荡,久久不绝。


经诊断,数据库发生性能指标异常,异常快照中的异常指标分析与性能指标显示:




进一步查看分析与cpu_usage相关的SQL(相关SQL,是将全量SQL的执行趋势图像化并聚类分类,建立了性能指标与SQL执行趋势指标的联系),可以看到:



“瑶池大夫,这个指标异常是哪里出现问题了?该怎么处理啊?”


妙手神医拿起诊疗报告,逐行向大家解释道:“来,看第一行,这里显示cpu_usage相关度接近1.0,说明SQL模板所在的类别与cpu_usage关联度最高,即该类SQL与异常性能指标的关联度最高。我们可以再查看这个类别内的SQL模板,按照执行次数或耗时ranking,就可以看到对这个指标异常贡献度最高的SQL模板。”


为了更加精准定位到某一类或某几类SQL模板,从而对症治疗,妙手神医瑶池在构建的SQL执行趋势以及数据库性能指标的关联关系的基础上,进一步精准定位造成异常的根因SQL和被影响SQL。于是,看到该异常事件的根因分析和建议:



“通过这里,我们可以看到,主要是第一行DELETE SQL模板的大量执行,造成实例CPU类指标、DML操作行数类指标、DML执行次数类指标的升高。针对定位到的异常SQL模板,可以查看对应的SQL样本,通过采取限流、优化等措施进行异常问题的止血与数据库性能的优化。”



2. 异常SQL无处藏身,根因分析对症下药


为了保证数据库的生命体征稳定,除了需要及时发现异常,也需要快速确定异常发生的原因,从而做到“对症下药”。云数据库性能异常的根因分析(Root Cause Analysis,RCA)旨在诊断检测到的数据库异常的根本原因。


因此,分析用户在数据库的SQL请求行为,并能够进行异常SQL的定位,是处理和解决数据库性能异常问题的关键。


在实际应用中,此类问题面临着如下挑战:


  • 随着业务量增长,实际的生产环境中数据量往往很大,在海量SQL的场景下,进行全量SQL的逐条分析与异常SQL的定位难度大,而且搜索耗时长,成本高;


  • 单纯对全量SQL使用topN的方法寻找SQL,如只寻找执行耗时长的SQL,会损失大量的潜在问题SQL,异常SQL定位的召回率低;


  • 异常检测分析出的异常指标,难以直接建立其与用户SQL请求的联系,无法闭环分析。


凭借多年数据库诊疗经验,妙手神医瑶池已经研制出一套成熟的“异常SQL”诊疗方案——根因SQL分析,能够从容应对各种“性能异常”症状。在琅风山数据库恢复留观期内,妙手神医瑶池为大家详细介绍了这套诊疗方案。


2.1 建立SQL请求与异常性能指标的联系

2.2.1 数据收集&异常监测



首先收集依赖的云数据库中用户的SQL请求日志数据和数据库的性能数据:


▶︎ 其中对于SQL数据,由于全量SQL数据量庞大难以逐一分析,需要对SQL数据进行模板化处理,用于后续对各类SQL模板的聚类分析。例如一条SQL模板SELECT * FROM user table WHERE uid = ? 可能包含以下的SQL请求:


SELECT*FROM user tableWHERE uid =123456SELECT*FROM user tableWHERE uid =654321SELECT*FROM user tableWHERE uid =123321


?号模板化了具体的uid。


▶︎ 性能数据用于异常检测。分析用户关注和功能支持的性能指标是否发生了异常,关注性能指标的异常特征(spike,trend,level shift),从而确认异常现象,如DML变化,从而开始建立指标与相关SQL请求的联系。


2.1.2 SQL模板聚类


数据收集和异常检测之后,进行SQL模板的聚类,关注的是SQL执行趋势指标的相似度。



在实际应用中,我们关注的是异常时间段,因此可以选择异常开始发生时间段内执行的SQL模板,分析这些模板在异常前一段时间(如30~60min)不同SQL指标的执行趋势的相似度。


接下来,基于图分析的算法,对SQL执行趋势的不同指标分别进行相似度聚类。即当业务存在大量请求的时候,按照SQL请求行为对SQL模板进行分类。聚类后,全量SQL的分析种类大大减少,2000页的SQL可以按类归为10页,解决了通过排序很难一个个去筛选问题SQL的问题,帮助用户将大量的SQL模板聚类,由此提高问题定位的效率,极大的缩短了分析时间。


2.1.3 性能指标关联的SQL请求行为分析



接着,对聚类分类后的SQL模板,进行性能指标关联的SQL请求行为分析。主要是计算SQL执行趋势聚类后的簇与性能指标的相似度,将相同时间范围的不同指标的性能数据,与聚类结果中不同簇的SQL执行趋势关联起来。


在应用中,可以ranking分析SQL执行趋势聚类后的簇与性能指标的相似度。如上图中的性能指标尖刺,对应可以找到执行趋势相关的问题SQL。通过这些分析,可以实现根据指标的异常时间段来排查与异常指标相关的问题。


2.2 定位根因SQL

2.2.1 指标相关的聚簇筛选


异常SQL定位的实现基于SQL模板聚类。


在对SQL模板聚类分类后,繁杂且大量的SQL模板已经按照相应的执行趋势与性能指标的相关程度聚类分类。为了进一步精准定位异常SQL,首先需要进行聚簇筛选,进一步缩小目标范围。


筛选主要分两个条件:


a. 对于一个聚簇,我们认为该聚簇对异常指标的贡献度,就是该聚簇里所有SQL模板中对异常指标最大的影响值。



b. 为了能尽可能多的将异常SQL所在的聚簇筛选出来,因此除了第一个条件,我们还计算同一个聚簇中的同一类SQL模板的累计影响值。



然后综合第一条件中的最大影响值和第二个条件中的累计影响值是否达到阈值,判断是否选择某个聚簇作为根因SQL候选聚簇。


2.2.2 根因SQL&被影响SQL定位



通过聚簇筛选,获得了用于定位根因SQL和被影响SQL的candidates,进行最后的根因SQL和被影响SQL的定位。


我们的先验知识是,平稳的流量通常是不会造成指标的异常现象的。所以在定位时,可以将异常事件的异常执行趋势,与异常前一段时间的历史执行趋势做比较,辅助定位根因SQL。然后综合不同指标和异常现象间的传播关系,以及使用SQL模板的执行趋势指标和实例性能指标之间的相关性进行分析,可以精准定位根因SQL和被影响SQL。


这里举一个分析过程的示例:一种SQL模板造成了锁等待现象,就会影响锁等待相关的指标。锁等待现象的发生,会造成某模板集合的SQL被阻塞,就会造成session突增。被阻塞的集合中CPU密集型SQL又会被阻塞,造成CPU突增。通过这样的传播关系,就可以定位到具体的根因SQL和被影响SQL。



异常SQL定位可以支持数据库多种根因定位场景的动态扩展,并辅助进行数据库性能的优化,用于后续多种自动修复场景,包括SQL限流、SQL优化等。



3. 根因SQL分析使用场景


萦绕在山间的烽烟渐渐退去,琅风山数据库生命体征已趋于平稳,妙手神医瑶池对众人叮嘱道:


「根因SQL分析」是瑶池派一套成熟的‘异常SQL’诊疗方案,在后期的恢复中,大家可以通过SQL洞察功能持续关注身体情况。”


随后,妙手神医瑶池开出一张诊疗单,详细说明了「根因SQL分析」功能的支持场景与指标:


支持的引擎与场景包括:MySQL支持10类30多种性能指标的关联,PolarDB MySQL支持6类近20种性能指标的关联。当前分析依赖全量SQL汇聚数据(SQL洞察)、基于performance_schema能力汇聚的SQL数据(性能洞察)


支持的监控指标包括:DML执行次数类指标、DML操作行数类指标、线程池指标、实例CPU类指标、实例内存指标、缓冲池指标、逻辑IO类指标、物理IO类指标、实例磁盘空间类指标、其他。


被关联的SQL指标包括:按照SQL的执行次数、按照SQL的总执行耗时、按照SQL的总扫描行数、按照SQL执行的锁等待时间、按照SQL执行的逻辑读、按照估算的SQL执行的CPU消耗,共6类执行趋势指标。


不久后,琅风山恢复了往日的有序和平静。妙手神医瑶池依然行走于风云之中,在纷争林立的数据江湖书写着一个又一个新的故事




数据库自治服务DAS是一种基于机器学习和专家经验实现数据库自感知、自修复、自优化、自运维及自安全的云服务让数据库实现了“自动驾驶”,够帮助用户消除数据库管理的复杂性及人工操作引发的服务故障,有效保障数据库服务的稳定、安全及高效。

点击「链接」了解 数据库自治服务DAS 更多信息。



END


🎁🎁🎁

参与微信公众号文章留言互动,赢取精美好礼


欢迎在微信公众号搜索「阿里云瑶池数据库」or 微信扫描下方二维码查看更多「妙手神医瑶池」系列故事,参与本期互动还有机会赢取限定好礼参与文末留言《福利贴|妙手神医瑶池:寻根溯源,哪条SQL导致了性能异常?》小编将选取精选留言点赞数👍最多的前三名幸运er,送出瑶池数据库限量礼品」哦~

阿里云瑶池数据库二维码-1m距离扫码.jpg

阿里云瑶池数据库

留言精选截止日期:12月15日18:00

点赞互动截止&获奖通知日期:12月19日14:00


点赞数第一名:云小宝超萌回弹解压笔记本*1


点赞数第二、第三名:定制款飞盘*1


快来评论 / 点赞 / 分享

喊上你的小伙伴快来微信文章留言区助力赢取限量好礼吧~

相关实践学习
使用DAS实现数据库自动扩容和回缩
暂无
相关文章
|
1月前
|
SQL 数据库 UED
SQL性能提升秘籍:5步优化法与10个实战案例
在数据库管理和应用开发中,SQL查询的性能优化至关重要。高效的SQL查询不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将分享SQL优化的五大步骤和十个实战案例,帮助构建高效、稳定的数据库应用。
63 3
|
1月前
|
SQL IDE 数据库连接
IntelliJ IDEA处理大文件SQL:性能优势解析
在数据库开发和管理工作中,执行大型SQL文件是一个常见的任务。传统的数据库管理工具如Navicat在处理大型SQL文件时可能会遇到性能瓶颈。而IntelliJ IDEA,作为一个强大的集成开发环境,提供了一些高级功能,使其在执行大文件SQL时表现出色。本文将探讨IntelliJ IDEA在处理大文件SQL时的性能优势,并与Navicat进行比较。
33 4
|
1月前
|
SQL 存储 缓存
如何优化SQL查询性能?
【10月更文挑战第28天】如何优化SQL查询性能?
149 10
|
1月前
|
SQL 关系型数据库 MySQL
惊呆:where 1=1 可能严重影响性能,差了10多倍,快去排查你的 sql
老架构师尼恩在读者交流群中分享了关于MySQL中“where 1=1”条件的性能影响及其解决方案。该条件在动态SQL中常用,但可能在无真实条件时导致全表扫描,严重影响性能。尼恩建议通过其他条件或SQL子句命中索引,或使用MyBatis的`<where>`标签来避免性能问题。他还提供了详细的执行计划分析和优化建议,帮助大家在面试中展示深厚的技术功底,赢得面试官的青睐。更多内容可参考《尼恩Java面试宝典PDF》。
|
1月前
|
SQL 缓存 监控
SQL性能提升指南:五大优化策略与十个实战案例
在数据库性能优化的世界里,SQL优化是提升查询效率的关键。一个高效的SQL查询可以显著减少数据库的负载,提高应用响应速度,甚至影响整个系统的稳定性和扩展性。本文将介绍SQL优化的五大步骤,并结合十个实战案例,为你提供一份详尽的性能提升指南。
51 0
|
2月前
|
SQL 监控 数据库
慢SQL对数据库写入性能的影响及优化技巧
在数据库管理系统中,慢SQL(即执行缓慢的SQL语句)不仅会影响查询性能,还可能对数据库的写入性能产生显著的不利影响
|
2月前
|
SQL 关系型数据库 PostgreSQL
遇到SQL 子查询性能很差?其实可以这样优化
遇到SQL 子查询性能很差?其实可以这样优化
147 2
|
2月前
|
SQL Oracle 关系型数据库
Oracle SQL:了解执行计划和性能调优
Oracle SQL:了解执行计划和性能调优
75 1
|
2月前
|
SQL 存储 数据库
慢SQL对数据库写入性能的影响及优化技巧
在数据库管理系统中,慢SQL(即执行缓慢的SQL语句)不仅会影响查询性能,还可能对数据库的写入性能产生显著的不利影响
|
2月前
|
SQL 数据处理 数据库
SQL语句优化与查询结果优化:提升数据库性能的实战技巧
在数据库管理和应用中,SQL语句的编写和查询结果的优化是提升数据库性能的关键环节