当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破( 二 ) 导读：VLDB2020（The46thInternational

文章插图
而在众多慢SQL当中，有一类SQL的执行时间比他历史执行时间要慢的多，这时候我们就应该引起注意了，同样的SQL为什么会执行变慢？我们发现很多故障的前兆都伴随这种SQL的出现，所以我们尝试给这类SQL下一个统一的定义。
文章插图
大部分iSQ都会影响用户体验，站在用户视角，他们本身执行的SQL突然变慢了，用户是可以感知到的。但是为什么不用其他指标取衡量呢？
Tcp-RT是一个不错的指标，他也可以反应查询的RT ，但是SQL模板是细粒度的指标，而RT是全局维度的指标，很多场景下，当用户QPS升高的时候， Tcp-RT是下降的；某些场景下，整体RT没有变慢而某类SQL模板执行变慢了；所以全局维度指标往往是有局限性的，这就是为什么我们需要通过下钻进行根因定位。
文章插图
因此，对比慢SQL的定义，我们给出了iSQ的定义，并相信通过iSQ方式筛选出来的SQL更能体现出数据库运行的状态。通过SQL执行时间>1s,这个规则并不能帮助用户很好的筛选真正的问题SQL 。这里我们通过概率的方式比较简单了定义了iSQ ，当然我们未来也会根据SQL执行的更多特征，借助更多"数据驱动"的方式筛选出iSQ 。
文章插图
Autonomous Diagnose
因此我们找到了一个根因定位的一个切入点，通过找到iSQ产生的根因来诊断数据库的性能问题。我们发现传统慢SQL的定义是通过阈值来定义的，这种规则驱动的方式并不能很好的帮助用户缩小全量SQL的范围，我们发现当数据库出现比较阻塞，密集型Workload ，锁问题的时候，常常会出现iSQ(iSQ Intermittent Slow Queries ，云数据库发生故障的时候， iSQ往往会提前出现，由于iSQ在其他时间段内执行时间并不慢， SQL的执行时间返回突然增长会导致业务的巨大变化,或者是由于业务变化受影响的）通过对于iSQ的根因定位，我们可以对数据库常用的故障进行跟细粒度的根因定位，只有将数据库的现象进行分类，我们后面的自修复/自优化Actions才可以减少action执行的冲突，合理的schedule我们的自治action ，有效的给用户提供合理的自治建议并发出自治action ，形成闭环。
文章插图
挑战
Anomaly Diversity
在与DBA排查问题的过程中，我们发现排查问题， DBA往往要浏览超过20个指标，通过监控页面的对比，以及多指标的时序特征来确定大致的原因。例如尖刺/均值漂移是DBA最关注的特征，当然例如周期性和趋势线的特征也是DBA关注的。
文章插图
Labeling Overheads
DBA 在标注case的时候要花大量的时间，而标注往往是case by case ，所以我们case的沉淀往往是通过故障文档或者工单，所以我们想到几个突破点：