简介：对于异样SQL中存在的业务属性的相似性以及盘根错节的影响与被影响的关系，理分明问题SQL与各种资源的异常现象的流传关系是具备挑战的。DAS团队依然在如何找到异样SQL这个课题上持续进行了钻研和摸索，在摸索的过程中咱们提供了一个新的剖析性能SQL申请行为辨认帮忙用户更好的定位SQL问题。

业务背景:

DAS(Database autonomy service)为上百万数据库实例的稳固运行保驾护航，其中精准定位数据库运行过程中的异样SQL是DAS最根本的性能。数据库90%以上的问题都来源于数据库的异样申请，无论是双十一的团体海量交易申请行为，还是用户业务变动的申请行为，每时每刻都影响着数据库的性能。主动驾驶汽车通过感知路况图像变动的行为来把握车的方向，而主动驾驶数据库通过感知和辨认用户申请行为来一直修复优化数据库的各种问题，为云数据库保驾护航。如何从海量数据库中的海量申请定位出不同数据库引擎不同场景的问题是多年以来困扰DBA的难题。在举荐畛域，通过剖析用户的行为习惯代替了机械式网页展现精准举荐给用户冀望的文字/视频/产品，晋升用户体验和产品转化率，同样下一代数据库主动驾驶平台也须要剖析用户申请行为，用户开发业务行为，举荐出相应优化修复扩容等操作，晋升主动驾驶数据库的效率，让数据库更快更稳更平安。所以从用户申请行为和业务行为登程，在海量数据库实例的海量申请中进行数据挖掘是一个十分值得深入研究的课题，同时也是数据库主动驾驶平台十分依赖的底层技术能力, 向上撑持DAS数据库自治服务各个场景的自治能力。

DAS这这些年提供了多个对SQL数据进行剖析的L2性能包含：专业版SQL洞察，全量SQL，慢日志， 一键诊断， 锁剖析，会话等。每一个性能积淀了DBA在不同角度剖析不同问题的办法，不同实例，不同业务诊断问题的办法略有不同。对于并不是很相熟DB运维的用户来说，DAS在提供一个对立高效简略的形式去帮忙用户去定位问题。咱们联合SQL变慢的多指标特色，提出一种基于特色类似度匹配的办法 VLDB 2020 积淀到自治核心性能当中, 但对于异样SQL中存在的业务属性的相似性以及盘根错节的影响与被影响的关系，理分明问题SQL与各种资源的异常现象的流传关系是具备挑战的问题，DAS团队依然在如何找到异样SQL这个课题上持续进行了钻研和摸索，在摸索的过程中咱们提供了一个新的剖析性能SQL申请行为辨认帮忙用户更好的定位SQL问题。

问题形容:

以下图为例，实例CPU呈现尖刺突增的景象，数据库有cpu打满潜在危险，当用户的申请量较少或者申请的SQL模式较少的时候，通过指标的排序筛选是很容易找到问题SQL的，但当用户的全量SQL模板超过上万甚至上亿条，用户通过以后DAS页面无奈疾速定位异样SQL，咱们须要通过更多数据提供更高效的形式，来定位异样申请。

当用户应用DAS专业版SQL洞察的性能的时候，即便咱们将全量SQL流水，压缩聚合成模板，模板的数量也是惊人的，咱们能够看到大量特色趋势相近的模板。所以如果咱们依据SQL的申请行为将模板进一步压缩，这样用户能够更好的定位异样SQL的问题

目前DAS产品性能和业界AWS Azure等其余产品都有初步的异样SQL定位能力，通过对采集的SQL数据在各个维度的排序，让用户本人定位数据库问题，这种形式对于80%以上简略的数据库问题是无效的，然而在简单业务场景和DBA都很难定位的数据库问题成果是很差的。以阿里云外部管控的元数据库集群实例为例，往年均匀每月产生10屡次的CPU打满问题，全年产生数次性能相干的故障问题，然而每次的问题都不同，有时候DBA只能找到景象，难以疾速定位问题根因。所以通过对用户申请行为的剖析，会更好的迭代DAS数据库自治服务产品，解决咱们简单场景的数据库性能问题，进步整个数据库各个引擎的稳定性，易用性，效率。

业界产品:

AWS: RDS： Performance Insight

和目前DAS产品性能一样，采集的数据维度相似，通过Top N ranking的形式进行异样SQL定位，没有SQL申请行为剖析性能

Azure: Query Performance Insight

通过取Top N的形式对SQL申请进行定位，能够定位到60%的显著问题，然而无奈定位SQL申请简单业务的数据库问题，没有SQL申请行为剖析性能

腾讯云：DB Brain性能，和目前DAS现有性能相似，没有SQL申请行为剖析性能

华为云：Database Admin Service，和目前DAS现有性能相似，没有SQL申请行为剖析性能

挑战&难点

Challenges:

规模化挑战:

The sea of performance issues in the sea of queries from the sea of the databases

用户的业务申请丰盛，如何从海量数据库实例中的海量申请中定位多种数据库引擎的性能问题。

监控诊断挑战：

7*24 real time anomaly detection => 7*24 root cause analysis in near real time

针对潜在的SQL申请导致的数据库性能问题，根因定位须要做到近实时问题定位。

繁冗的数据库异常现象：

异样指标通常与多条SQL申请无关，无奈用单条SQL来解释异样起因且多个业务的SQL申请之间相互影响，关联的问题包含全表扫描/索引/锁问题/缓存击穿/内核问题等。多个问题在指标景象存在相似性和不同Motivations:

人工根因定位：

帮忙DBA或用户解决性能问题，工单问题

帮忙后端开发人员合理安排申请查问的流程，尽量让资源密集型申请从业务角度打散

帮忙DBA找到不同申请之间在业务层面间接和间接的关系。

赋能自治服务：

更加精细化的限流: Limit anomalous SQL more meticulous

更加精确对workload预测: Forecast workload more accurate

更好的划分workload: Workload can be well-partitioned

更好的预估自治操作的资源收益: Estimate the SQL Resource Cost for autonomous actions

在第一工夫解决潜在的性能问题：Crack the potential performance issue at the first place

DAS解决方案:

启发思路：

在很多后端利用开发的过程中，后端架构设计往往会保障接口的幂等性，例如我的项目中为了解决timeout问题，通常会引入重试机制，有时候会申请反复数据，生产音讯有时候读反复数据之类的幂等性问题。例如屡次insert或update可能会造成数据谬误。

为了解决这些幂等性的办法，后端通常会应用这些形式例如 先select再insert，加乐观锁/乐观锁/分布式锁，或者依据状态机来治理有状态的业务。

领取场景状态机示例：

......

update \`bill\` set status=1 where id=520 and status=0;

下单行为 SQL A

update \`bill\` set status=2 where id=520 and status=1;

领取行为 SQL B

update \`bill\` set status=3 where id=520 and status=2;

勾销订单行为 SQL C

.....

所以同一个业务流程会随同这多个SQL申请，串行或并行，这就意味着这些SQL在执行趋势上存在这关联性，这种关联性和业务无关。当咱们发现业务异样的时候，同时随同这指标异样，所以当咱们定位异样SQL的时候，同一业务下的SQL都会有异常现象，所以通过这些SQL的趋势特色咱们能够将海量SQL数据进行通过算法进行聚类。所以咱们想到通过剖析SQL的同源性，站在业务视角来定位异样SQL，能够更有效率的定位异样SQL

流程框架：

感知过程：

在诊断的过程中，DAS后端首先从对立数据层(DataSet Layer)申请，性能数据(Perf Data)和SQL申请数据（SQL Query Data），性能数据通过多指标异样检测(MTS Anomaly Detection)/特征提取(Feature Extraction)

异样申请定位过程：

示例：

模板汇合X:{sql\_a , sql\_b, sql\_c} ==> 影响了 mysql.cpu\_usage 指标变动 

         ==>sql 汇合的影响水平 (推算cpu\_time占比)

模板汇合Y: {sql\_i , sql\_j, sql\_k } ==> 影响了 mysql.active\_session 指标变动 

         ==> sql 汇合的影响水平 (推算session占比)

感知层感知到时序指标异样后，通过全量SQL通过模板化解决后的数据，使用Graph Based的聚类办法，将海量的SQL依照申请行为的特色进行划分，最初依据聚合后申请行为的贡献度评分进行排序(Query Behavior Ranking)，检测异样申请及其作用于性能指标的景象.

根因剖析过程：

示例：

烂SQL模板 sql\_i --> 造成了锁期待景象---> 影响了mysql.rows\_lock\_wait\_time指标 

               --> 造成模板Y汇合的SQL被阻塞 -->  造成session的突增 

               --> 被阻塞的Y汇合中X汇合中的CPU密集型SQL被阻塞 --> 造成了CPU突增 

通过SQL解释了指标异常现象之后，还有很多故障问题咱们无奈精确定位，例如主备提早,锁问题,OOM,内核问题等，这些问题可能导致了执行SQL的耗时减少，反过来，SQL也有可能产生这些问题的景象。

(Anomaly Propagation Analysis )帮忙咱们对这些景象之间，进行流传关系的剖析。这里的剖析咱们通过工夫先后关系联合咱们历史案例数据综合进行比对, 最初将得出的异样流传链和整个DAS剖析过程和倡议并增加到后端的case库并更细case model。Case Model会依据反馈一直叠加调整匹配参数，给出更精准的倡议。

基于申请行为辨认的异样SQL定位案例:

定位会话(active\_session)突增尖刺问题：

下图数据库实例沉闷会话有异样的尖刺，这种尖刺持续时间过长，对一些敏感业务会有造成潜在的问题，咱们想要定位尖刺的起因，首先DAS的实时异样检测能够检测出多指标的异样时间段。对于CPU，沉闷会话异样的检测会透传出黄色异样事件的提醒。

沉闷会话通常和总执行耗时强相干，通过SQL申请行为剖析抉择对应指标，并点击剖析

找到和会话类似的指标，并点击查看，依照总耗时排序，能够找到对会话异样"奉献"最大的异样SQL，

点击对应SQL\_ID 查看详情，通过趋势行为ranking的后果，能够分明的看到这个SQL变慢了和历史趋势相比变慢了。通过执行趋势能够看到异样趋势和历史趋势齐全不同，且与沉闷会话异样的趋势相吻合

最终定位：这条SQL执行次数突增(从1000次执行超过8000屡次)，导致其余SQL执行耗时变慢，造成了沉闷会话沉积产生了active\_session指标突增景象

CPU打满(cpu\_usage)突增问题：

下图数据库实例CPU被打满，

除了SQL设计CPU密集型计算诸如join，等比拟低廉的操作外，绝大部分状况，CPU和扫描行数成正相干，在SQL申请行为剖析抉择，cpu\_usage和总扫描行数,

咱们比拟容易定位到和CPU关联的指标

最终定位：这条全表扫描的SQL，造成了CPU被打满从而导致了会话的沉积

将来打算

DAS会反对更多引擎的实时检测和异样定位，专业版联合用户的全量SQL帮忙更多用户定位更多类型的数据库实例问题。不仅让业余DBA更好的应用DAS管控数据库实例，也让数据库畛域的初学者无门槛的管控数据库，真正保障数据库实例自感知，自优化，自修复。

**相干浏览：
**

数据库自治服务DAS公布年度新版本：1-5000，”数据库主动驾驶“进入规模化时代

深度技术揭秘 | 大促狂欢背地，如何无效评估并布局数据库计算资源？

重磅 | 数据库自治服务DAS论文入选寰球顶会SIGMOD，领航“数据库主动驾驶”新时代

性能更新｜DAS推出全局Workload优化性能，实现SQL主动诊断

干货｜一文读懂阿里云数据库Autoscaling是如何工作的

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。