关于sql:重磅发布｜新一代云原生数据仓库AnalyticDBSQL智能诊断功能详解

简介：AnalyticDB For MySQL 为用户提供了高效、实时、功能丰富并且智能化的「SQL 智能诊断」和「SQL 智能调优」性能，提供用户 SQL 性能调优的思路、方向和具体的办法，升高用户应用老本，进步用户应用 ADB 的效率。

SQL 是一种简略易用的业务逻辑表白语言，但随着扫描数据量和查问复杂度的减少，查问性能会变得越来越慢。想要对 SQL 进行调优，往往须要关注以下几个局部：

• 须要理解引擎架构：用户往往须要对 SQL 引擎的架构特点有肯定的理解，能力和业务的数据分布特色以及业务场景特色完满联合，来进行数据建模，从而设计出合乎 SQL 引擎架构特点的表构造。
• SQL 特色差别较大：即席查问的 SQL 往往变动较大，包含参加 Join 的表个数、Join 条件、分组聚合的字段个数以及过滤条件等。
• 数据特色差别较大：用户的数据分布特色是会随着业务特色的变动而变动的，如果始终依照最后的建模形式和 SQL 语句，也是无奈保障能施展出 SQL 引擎的最大劣势，数据特色或者业务模型的变动，都会导致 SQL 性能回退。

基于此，AnalyticDB For MySQL（新一代云原生实时数据仓库，语法兼容 MySQL，以下简称 ADB）为用户提供了高效、实时、功能丰富并且智能化的「SQL 智能诊断」和「SQL 智能调优」性能，提供用户 SQL 性能调优的思路、方向和具体的办法，升高用户应用老本，进步用户应用 ADB 的效率。

上面咱们通过「发现慢查问」+「诊断慢查问」两个步骤，并联合一个场景 Case，来介绍 ADB 新公布的「SQL 智能诊断」性能。（PS：「SQL 智能调优」会在后续版本中公布）

一、发现慢查问

用户要定位慢查问，首先须要找到慢查问。ADB 的用户控制台提供了多样的形式来帮忙用户，例如「甘特图」和「查问列表」等，都能够在多个维度进行检索，帮忙用户疾速定位慢查问，而且诊断工具确保用户能够进行最近两周的全量查问检索和剖析。

（一）甘特图

用户能够通过「集群控制台」-「诊断与优化」–「SQL 诊断」进入 SQL 智能诊断性能。

首先会看到一个甘特图（也称泳道图，查问从不同的泳道流过，这里的泳道并不是 ADB 的查问队列，只是为了辨别开不同工夫执行的查问），甘特图以图形化的形式形象的展现了查问在 ADB 实例上的执行程序，每个色块示意了一条查问，色块左侧为查问的提交工夫，色块右侧为查问的完结工夫，色块的绝对长度示意了某条查问的执行工夫，色块的色彩没有非凡含意，只是为了辨别不同的泳道。

通过甘特图，用户能够十分直观的看到以后工夫范畴内执行耗时较长的查问，并且能够直观的看到哪些查问是在并行的执行以及并行执行的时间段，这能够帮忙用户判断出哪些查问是受到了某条 Bad SQL 的影响。色块的密集度则能够用来直观的判断 ADB 实例压力较大的时段是否和某些查问的并发度较高相干。

（二）查问列表

甘特图可能以直观的形式体现出查问之间的工夫相关性，然而当用户抉择的工夫范畴较大，甘特图中的色块会密集散布不容易分辨，而且甘特图上的指标较为无限，此时用户能够应用诊断工具中的查问列表性能。查问列表提供了多大 10 余项查问级别的重要指标，例如数据库名、用户名、客户端段 IP、耗时、耗费内存以及扫描量等，这些信息和指标能够帮忙用户进一步判断慢查问的起源和资源耗费等。

高级检索能力方面，诊断工具提供了三种类型的检索办法：

1. 含糊检索和准确检索：用户能够依据 SQL 中的关键字进行含糊匹配，准确检索性能则帮忙用户在确定查问 ID 的状况下，准确的检索到这条查问；
2. 字符串类型的检索条件：检索工具会自动识别出用户所选工夫范畴内应用的数据名、用户名、客户端 IP 以及资源组等，提供下拉框的模式供用户抉择，进步用户检索效率；
3. 数值类型的检索条件：用户能够自由选择检索的指标单位，例如 KB、MB、GB 等，不须要进行手动的换算。

同时，用户在应用诊断工具时，往往有对慢查问的下载需要，下载后的慢查问能够在例如 Excel 等工具中进行更多自定义的慢查问治理和剖析，所以咱们也提供了查问列表的下载性能。

二、诊断慢查问

（一）查问在 ADB 中的执行流程

在介绍 ADB 执行流程前须要简略介绍一下三个相干的基本概念：

• Stage

在执行阶段，ADB 中的查问会首先依据是否产生 Shuffle 被切分为多个 Stage 来执行，一个 Stage 就是执行打算中某一部分的物理实体。Stage 的数据起源能够是底层存储系统中的数据或者网络中传输的数据，一个 Stage 由散布在不同计算节点上雷同类型的 Task 组成，多个 Task 会并行处理数据。

• Task

Task 是一个 Stage 在某个 Executor 节点上的执行实体，多个同类型的 Task 组成一个 Stage，在集群外部并行处理数据。

• Operator

Operator（算子）是 ADB 的最小数据处理单元。ADB 会依据算子所表白的语义或算子间的依赖关系，决定应用并行还是串行执行来解决数据。

上面以一个典型的分局聚合查问为例来理解 ADB 中查问的执行流程，SQL 语句如下：

SELECT COUNT(*), SUM(salary)

FROM emplayee

WHERE age>30 ADN age<32

GROUP BY sex

在 ADB 外部，首先由前端的 Controller 节点接管 SQL 语句申请，并对 SQL 语句进行语句解析和语法分析（Parser），最初应用优化器（Optimizer）生成最终的执行打算，整体执行打算会依据 Stage 的划分准则被切分为子打算，如图中的 Plan0、Plan1 和 Plan2，别离被下发到对应的节点上。

其中子打算 Plan2 会并行的在 4 个计算节点上以 Task 实例的模式解决数据，首先执行数据的扫描和过滤，而后执行数据的部分聚合，解决完之后的数据会依据 sex 字段 Repartition 到上游的计算节点，即 Stage1 的节点，依照子打算 Plan1 的要求执行数据的最终聚合。最初，数据由 Stage0 的节点汇总并返回到客户端。

和典型的数据仓库一样，ADB 的执行打算个别分为「逻辑执行打算」和「物理执行打算」：

• 逻辑执行打算：宏观层面理解查问的解决流程

逻辑执行打算在较高的层面展现查问的解决逻辑，基于规定的执行打算（RBO）会判断过滤条件是否能够下推，而基于代价的执行打算（CBO）会判断出多表关联时的程序等。所以逻辑执行打算并不关注在物理执行时的具体解决形式，例如是否在执行时须要对多个算子进行交融以缩小函数调用，或者主动生成代码的粒度，这些逻辑执行打算并不关注，这也就导致了逻辑执行打算往往只蕴含了 Stage 级别的执行统计信息。然而用户调优时往往是须要准确到算子级别的统计信息。

• 物理执行打算：宏观层面理解每个算子的解决性能

绝对于逻辑执行打算，物理执行打算蕴含了算子间的数据处理流图，也蕴含了算子的执行统计信息，能够准确的看到某个 Join 算子或者聚合算子占用的内存，也能够看到过滤算子过滤前后的数据量。然而并不是所有的算子用户都须要能正确理解其含意，特地是有些物理算子和用户的 SQL 语句找不到关联之处，这也会给用户独自应用物理执行打算定位问题带来较大的纳闷。

ADB 的「SQL 智能诊断」性能，提供给了用户一个逻辑执行打算和物理执行打算的交融视图，用户应用交融的执行打算即能够从宏观层面理解查问的解决流程，也能够从宏观层面理解每个算子的解决性能，从而能够更加精确疾速的帮忙用户定位查问的性能瓶颈点。

（二）SQL 自诊断性能

尽管咱们提供了交融的和分层的执行打算来帮忙用户剖析查问的性能问题，然而咱们发现在两类场景中用户应用交融执行打算会遇到困难：

ADB 的高级使用者

ADB 为了缩小 MySQL 用户的学习和迁徙老本，做到了绝大多数语法和 MySQL 兼容，然而 ADB 的后盾并非 MySQL 内核，而是独立自研的一套分布式数据存储和分布式计算零碎，面对 ADB 的执行打算，ADB 的高级使用者往往不晓得优化的重点在哪里，无从下手。

ADB 中的简单 SQL

对于简单的 SQL，往往波及几百张表的连贯操作，Stage 个数会达到几百个以上，算子个数更是会达到上千，执行打算图十分大，即便是 ADB 的高级使用者，面对这样简单的执行打算，往往也无从下手，如下图是个 196 个 Stage 的执行打算图：

针对以上问题，咱们在执行打算图中退出了 SQL 自诊断能力，SQL 自诊断能力会将专家教训以规定的模式体现在执行打算中，对于 ADB 的首次接触者，即能够依据诊断后果确定查问执行过程中的性能瓶颈点，也能够依据诊断后果学习到 ADB 执行打算中须要关注的重点算子。针对简单执行打算，SQL 自诊断能够帮忙用户疾速定位到执行打算中须要调优的地位，并提供了调优的相干办法和文档，让用户在调优过程中更有针对性。

SQL 自诊断能力通过「Query 级别诊断后果」、「Stage 级别诊断后果」、「算子级别诊断后果」这三层来展现诊断后果和优化倡议。

咱们以一个线上的简单 SQL 为例来介绍应用执行打算和 SQL 自诊断工具来进行性能问题定位的例子。首先咱们通过慢查问检索工具搜寻到一个内存耗费较大的查问，点击「诊断」关上该查问的诊断页面，切换到「执行打算」页签，咱们会看到查问级别诊断后果曾经判断出以后查问数据一个内存耗费较大的查问，如下图中的 1 所示：

这时，咱们须要定位内存成果较大的起因，咱们点击按内存排序，能够看到在右侧，会依据 Stage 耗费的内存百分比进行了顺叙排序，能够非常明显的看出，Stage[1]占用的以后查问 87% 以上的内存比例，咱们点击 Stage[1]，诊断工具会主动聚焦到执行打算树的 Stage[1]的地位，点击 Stage[1]，咱们能够看到 Stage[1]的执行统计信息，同时，咱们能够看到在 5 的地位，提醒咱们以后 Stage1 外部有个算子占用内存较大，然而并没有详细信息，所以接下来，咱们须要进入到 Stage[1]的外部，看看 Stage[1]具体是哪个算子占用了较多内存。

点击「查看 Stage 执行打算」，进入到 Stage[1]外部，首先，咱们仍然依据内存排序，能够看到，其中的 Join[317]这个算子占用了整个 Stage 99% 以上的内存，点击该算子，算子执行打算树主动定位到以后算子，这时咱们就能够看到算子诊断后果的详细信息了，信息提醒咱们，在构建 Hash 表用户 Left Join 时，占用了较大的内存，诊断后果还提供了官网的调优文档链接，依据文档中给出的调优办法，咱们就能够缩小该算子的内存占用。

以上的例子通过「查问级别诊断后果」和「算子级别诊断后果」进行 SQL 性能问题定位的办法，咱们再来看一个「Stage 级别诊断后果」的例子。

如下图所示，咱们能够看到依据耗时排序后，Stage[10]的耗时比例最大，点击执行打算图中的 Stage[10]，能够在诊断后果栏看到两类诊断后果，一类是“Stage 诊断”，一类是“算子诊断”，其中的 Stage 诊断通知咱们以后 Stage 的输入数据有歪斜，并且通知咱们歪斜的字段是哪些（数据歪斜是分布式系统中重大影响性能的问题，Stage 输入数据歪斜岂但会过后以后 Stage 解决数据在工夫上存在长尾，而且会导致上游的数据处理存在长尾），同时能够看到有一个算子诊断后果，提醒咱们表扫描存在歪斜，那么咱们能够初步判断以后 Stage 输入数据歪斜是因为扫描了一个数据歪斜的表导致的。接下来咱们进入到 Stage[0]外部进行定位和剖析。

进入到 Stage 内存，咱们依据耗时排序，能够看到 TableScan 算子耗时最大，这时咱们点击 TableScan 算子，能够看到在诊断后果里，有对于该表数据歪斜的具体诊断后果信息，这张表因为数据分布字段抉择的不适合，存在重大的数据歪斜问题，同时能够看到有相干的官网调优文档，咱们依据调优文档，就能够调整为适合的散布字段，缩小表数据歪斜对查问性能的影响。

通过以上的两个例子，咱们能够看到，交融执行打算和 SQL 自诊断性能，能够疾速的帮咱们定位到查问的性能问题，并给出肯定的调优倡议，缩小大量不必要的工夫和精力的节约，升高了高级使用者应用 ADB 的门槛。对于 SQL 自诊断更多的诊断后果能够参考官网文档：SQL 自诊断，目前曾经有 20+ 诊断规定上线，波及查问相干的内存耗费、耗时、数据歪斜、磁盘 IO 以及执行打算等多个方面，后续还有更多诊断规定陆续上线。

三、后续布局

通过以上的论述和例子剖析，能够看到以后的诊断调优工具曾经能够帮忙用户进行多方面的 SQL 性能问题排查，然而咱们在理论的线上问题解决和值班时依然发现总结了多个用户在剖析实例性能问题时的需要：

• 我应该调优哪些 SQL？

用户在关上诊断调优页面时，面对实例上运行的上万甚至上千万条 SQL，尽管能够通过耗时、内存耗费或者扫描量等进行排序来初步筛选出须要调优的 SQL，然而其实其实用户欠缺了一个特定诊断后果的视角，例如：

• 哪些 SQL 是数据扫描歪斜的？
• 哪些 SQL 是索引过滤不高效的？
• 哪些 SQL 是 Stage 输入歪斜的？
• 哪些 SQL 是分区抉择不合理的？

用户在针对某一个 SQL 的特定诊断后果调优实现后，其实须要晓得有哪些相似的 SQL 都须要调优的，所以咱们后续会提供给用户一个从特定诊断后果维度进行剖析的工具，一次性地解决某个特定问题。

• 我的 SQL 有问题，和建表形式不优无关吗？

ADB 后盾是一个分布式的数据存储和分布式的执行框架，依赖数据平均的散布到各个后盾节点上，同时 ADB 针对不同的业务场景设计了不同的表类型，例如分区表、复制表，有些表字段在存储时进行汇集存储，也会晋升查问性能，然而用户往往不晓得建表形式不优到底影响了哪些查问。后续咱们会把「数据建模诊断后果」和「查问诊断后果」关联，用户通过数据建模的诊断后果即可疾速晓得不良的表构造影响了哪些 SQL，同时反过来也能够通过某条 SQL 的诊断后果晓得哪些表须要优化。两类诊断后果联动调优，能够从本源上解决实例的查问性能问题。

四、总结瞻望

「SQL 智能诊断」性能曾经于近日上线，用户能够结合实际业务进行疾速上手应用。

原文链接
本文为阿里云原创内容，未经容许不得转载。