PolarDB-X 智能诊断之优化慢 SQL

传统单机数据库下，为了使数据库发挥出最大的性能，工程师们通常会设计出清晰的业务模型，减少JOIN操作，减少数据库的IO次数，增加索引等等方式。但是在使用分布式数据库情况下，数据分布在多个节点上，要优化查询性能，就有更多的方法选择：比如根据数据特点设计合适的拆分策略，尽量将JOIN操作下推，减少数据扫描行数，选择包括本地索引和全局二级索引在内的索引方案等等。

但是无论是单机数据库还是分布式数据库下，影响数据库性能的情况大部分和慢SQL相关，因此如何优化慢SQL是工程师们最常见的问题。慢SQL的优化方法一般先要准确地找到慢SQL，并且需要有该慢SQL的rt、返回行数、执行次数等等基本信息，可以帮助工程师快速判断慢SQL的影响范围和严重程度，然后进一步需要知道该慢SQL的真实执行计划，从而可以判断出数据库引擎可优化的具体执行计划算子，最后再根据基本信息和执行计划就可以分析出是需要添加索引，还是需要通过重新拆分数据或者强制指定算子等等方式来加速SQL语句。

根据以上思路，PolarDB-X智能诊断提供慢日志优化功能，可以帮助用户快速发现慢SQL，并且提供慢SQL的基本统计信息，还会帮用户分析出当时的执行计划，在此基础上更进一步地帮用户推荐出合适的索引优化方案，用户只需要一键复制便可直接执行索引创建操作来优化慢SQL。

原理简介

一条SQL会经过解析器、优化器、执行器，其中SQL的优化建议就是由优化器给出的，PolarDB-X优化器是以Volcano/Cascades模型作为框架的基于代价的优化器(Cost Based Optimizer)，它可以为每一条SQL构造出搜索空间，并根据数据的统计信息，基数估计，算子代价模型为搜索空间中的执行机计划估算出执行所需要的代价(CPU/MEM/IO/NET)，最终选出代价最小的执行计划作为SQL的具体执行方式。优化器详情可以参考：《PolarDB-X CBO 优化器技术内幕》

简单来说，一条逻辑SQL可以生成多种物理执行计划，要在众多的物理执行计划中选择出一条最优的，就需要进行执行计划的代价估算，从而找到代价最小的那条物理执行计划。PolarDB-X优化器会根据代价模型来进行代价评估，其中CPU消耗量、内存占用量、磁盘IO次数、网络逻辑IO次数会作为代价估算的计算指标。

我们以该SQL举例说明索引推荐的过程，详细原理可以参考《PolarDB-X 智能索引推荐技术尝鲜》：

SELECT sum(l_extendedprice) / 7.0 AS avg_yearly
FROM lineitem,
     part
WHERE p_partkey = l_partkey
  AND p_brand = 'Brand#23'
  AND p_container = 'MED BOX'
  AND l_quantity <
    (SELECT 0.2 * avg(`l_quantity`)
     FROM lineitem
     WHERE l_partkey = p_partkey);