本文介绍PolarDB-X 1.0的SQL执行器如何执行SQL中无法下推的部分。

基本概念

SQL执行器是PolarDB-X 1.0中执行逻辑层算子的组件。对于简单的点查SQL,往往可以整体下推存储层MySQL执行,因而感觉不到执行器的存在,MySQL的结果经过简单的解包封包又被回传给用户。但是对于较复杂的SQL,往往无法将SQL中的算子全部下推,这时候就需要PolarDB-X 1.0执行器执行无法下推的计算。

例如,对于如下查询SQL:

SELECT l_orderkey, sum(l_extendedprice *(1 - l_discount)) AS revenue
FROM CUSTOMER, ORDERS, LINEITEM
WHERE c_mktsegment = 'AUTOMOBILE'
  and c_custkey = o_custkey
  and l_orderkey = o_orderkey
  and o_orderdate < '1995-03-13'
  and l_shipdate > '1995-03-13'
GROUP BY l_orderkey;

通过EXPLAIN命令看到PolarDB-X 1.0的执行计划如下:

HashAgg(group="l_orderkey", revenue="SUM(*)")
  HashJoin(condition="o_custkey = c_custkey", type="inner")
    Gather(concurrent=true)
      LogicalView(tables="ORDERS_[0-7],LINEITEM_[0-7]", shardCount=8, sql="SELECT `ORDERS`.`o_custkey`, `LINEITEM`.`l_orderkey`, (`LINEITEM`.`l_extendedprice` * (? - `LINEITEM`.`l_discount`)) AS `x` FROM `ORDERS` AS `ORDERS` INNER JOIN `LINEITEM` AS `LINEITEM` ON (((`ORDERS`.`o_orderkey` = `LINEITEM`.`l_orderkey`) AND (`ORDERS`.`o_orderdate` < ?)) AND (`LINEITEM`.`l_shipdate` > ?))")
    Gather(concurrent=true)
      LogicalView(tables="CUSTOMER_[0-7]", shardCount=8, sql="SELECT `c_custkey` FROM `CUSTOMER` AS `CUSTOMER` WHERE (`c_mktsegment` = ?)")

如下图所示,LogicalView的SQL在执行时被下发给MySQL,而不能下推的部分(除LogicalView以外的算子)由PolarDB-X 1.0执行器进行计算,得到最终用户SQL需要的结果。

查询执行器

Volcano执行模型

PolarDB-X 1.0和很多数据库一样采用Volcano执行模型。所有算子都定义了open()next()等接口,算子根据执行计划组合成一棵算子树,上层算子通过调用下层算子的next()接口的取出结果,完成该算子的计算。最终顶层算子产生用户需要的结果并返回给客户端。

下面的例子中,假设HashJoin算子已经完成构建哈希表。当上层的Project算子请求数据时,HashJoin首先向下层Gather请求一批数据,然后查表得到JOIN结果,再返回给Project算子。

Volcano执行模型

某些情况下,算子需要将数据全部读取并缓存在内存中,该过程被称为物化,例如,HashJoin算子需要读取内表的全部数据,并在内存中构建出哈希表。其他类似的算子还有HashAgg(聚合)、MemSort(排序)等。

由于内存资源是有限的,如果物化的数据量超出单条查询限制,或者使用的总内存超出PolarDB-X 1.0节点内存限制,将会引起内存不足(OUT_OF_MEMORY)报错。

并行查询

并行查询(Parallel Query)指利用多线程并行执行用户的复杂查询。

说明 该功能仅在PolarDB-X 1.0标准版及企业版上提供,入门版由于硬件规格限制,不提供该项功能。

并行查询的执行计划相比原来有所改动。例如,还是以上面的查询为例,它的并行执行计划如下所示:

Gather(parallel=true)
  ParallelHashAgg(group="o_orderdate,o_shippriority,l_orderkey", revenue="SUM(*)")
    ParallelHashJoin(condition="o_custkey = c_custkey", type="inner")
      LogicalView(tables="ORDERS_[0-7],LINEITEM_[0-7]", shardCount=8, sql="SELECT `ORDERS`.`o_custkey`, `ORDERS`.`o_orderdate`, `ORDERS`.`o_shippriority`, `LINEITEM`.`l_orderkey`, (`LINEITEM`.`l_extendedprice` * (? - `LINEITEM`.`l_discount`)) AS `x` FROM `ORDERS` AS `ORDERS` INNER JOIN `LINEITEM` AS `LINEITEM` ON (((`ORDERS`.`o_orderkey` = `LINEITEM`.`l_orderkey`) AND (`ORDERS`.`o_orderdate` < ?)) AND (`LINEITEM`.`l_shipdate` > ?))", parallel=true)
      LogicalView(tables="CUSTOMER_[0-7]", shardCount=8, sql="SELECT `c_custkey` FROM `CUSTOMER` AS `CUSTOMER` WHERE (`c_mktsegment` = ?)", parallel=true)
并行查询

可以看出,并行执行计划中Gather算子的位置被拉高了,这也意味着Gather下方的算子都会以并行方式执行,直到Gather时才被汇总成在一起。

执行时,Gather下方的算子会实例化出多个执行实例,分别对应一个并行度。并行度默认等于单台机器的核心数,标准版实例默认并行度为8,企业版实例默认并行度为16。

执行过程的诊断分析

除了上文提到的EXPLAIN指令,还有如下几个指令能帮助分析性能问题:

  • EXPLAIN ANALYZE指令用于分析PolarDB-X 1.0 Server中各算子执行的性能指标。
  • EXPLAIN EXECUTE指令用于输出MySQL的EXPLAIN结果(并汇总输出)。

如下是以上文提到的查询为例,介绍如何分析一条查询的性能问题。

执行EXPLAIN ANALYZE得到如下结果(删除了一些无关的信息):

explain analyze select l_orderkey, sum(l_extendedprice *(1 - l_discount)) as revenue from CUSTOMER, ORDERS, LINEITEM where c_mktsegment = 'AUTOMOBILE' and c_custkey = o_custkey and l_orderkey = o_orderkey and o_orderdate < '1995-03-13' and l_shipdate > '1995-03-13' group by l_orderkey;

HashAgg(group="o_orderdate,o_shippriority,l_orderkey", revenue="SUM(*)")
... actual time = 23.916 + 0.000, actual rowcount = 11479, actual memory = 1048576, instances = 1 ...
  HashJoin(condition="o_custkey = c_custkey", type="inner")
  ... actual time = 0.290 + 23.584, actual rowcount = 30266, actual memory = 1048576, instances = 1 ...
    Gather(concurrent=true)
    ... actual time = 0.000 + 23.556, actual rowcount = 151186, actual memory = 0, instances = 1 ...
      LogicalView(tables="ORDERS_[0-7],LINEITEM_[0-7]", shardCount=8, sql="SELECT `ORDERS`.`o_custkey`, `ORDERS`.`o_orderdate`, `ORDERS`.`o_shippriority`, `LINEITEM`.`l_orderkey`, (`LINEITEM`.`l_extendedprice` * (? - `LINEITEM`.`l_discount`)) AS `x` FROM `ORDERS` AS `ORDERS` INNER JOIN `LINEITEM` AS `LINEITEM` ON (((`ORDERS`.`o_orderkey` = `LINEITEM`.`l_orderkey`) AND (`ORDERS`.`o_orderdate` < ?)) AND (`LINEITEM`.`l_shipdate` > ?))")
      ... actual time = 0.000 + 23.556, actual rowcount = 151186, actual memory = 0, instances = 4 ...
    Gather(concurrent=true)
    ... actual time = 0.000 + 0.282, actual rowcount = 29752, actual memory = 0, instances = 1 ...
      LogicalView(tables="CUSTOMER_[0-7]", shardCount=8, sql="SELECT `c_custkey` FROM `CUSTOMER` AS `CUSTOMER` WHERE (`c_mktsegment` = ?)")
      ... actual time = 0.000 + 0.282, actual rowcount = 29752, actual memory = 0, instances = 4 ...

其中:

  • actual time表示实际执行耗时(其中包含子算子的耗时),加号(+)左边表示open(准备数据)耗时,右边表示next(输出数据)耗时。
  • actual rowcount表示输出的行数。
  • actual memory表示算子使用的内存空间大小(单位为Bytes)。
  • instances表示实例数,非并行查询时始终为1,对于并行算子每个并行度对应一个实例。如果实例数不等于1,actual time,actual rowcount,actual memory代表多个实例并行执行的总实际执行耗时、总输出行数、总内存使用量。
说明 当使用并行查询时,上述的算子耗时、输出行数等信息均为算子多个实例的累加。例如actual time = 20,instances = 8,表示该算子有8个实例并行执行,平均耗时为2.5s。

以上面的输出为例,解读如下:

  • HashAgg算子open耗时为23.916s,用于获取下层HashJoin的输出、并对输出的所有数据做分组和聚合。其中的23.601s都用在了获取了下层输出上,只有约0.3s用于分组聚合。
  • HashJoin算子open耗时0.290s,用于拉取右表(下方的Gather)数据并构建哈希表;next耗时23.584s,用于拉取左表数据以及查询哈希表得到JOIN结果。
  • Gather算子仅仅用于汇总多个结果集,通常代价很低。
  • 左侧(上方)的LogicalView拉取数据消耗了23.556s,可判断这里是查询的性能瓶颈。
  • 右侧(下方)的LogicalView拉取数据消耗了0.282s。

综上,性能瓶颈在左边的LogicalView上。从执行计划中可以看到,它是对ORDERS、LINEITEM的JOIN查询,这条查询MySQL执行速度较慢。

您可以通过如下EXPLAIN EXECUTE语句查看MySQL EXPLAIN结果:

MySQL EXPLAIN结果

上图中,红色方框对应左边的LogicalView的下推查询,蓝色方框对应右边LogicalView的下推查询。