简介：对于异样 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
用户的业务申请丰盛，如何从海量数据库实例中的海量申请中定位多种数据库引擎的性能问题。
监控诊断挑战：
724 real time anomaly detection => 724 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 管控数据库实例，也让数据库畛域的初学者无门槛的管控数据库，真正保障数据库实例自感知，自优化，自修复。
原文链接
本文为阿里云原创内容，未经容许不得转载。