本文介绍PolarDB-X的SQL执行器如何执行 SQL中无法下推的部分。
基本概念
SQL执行器是PolarDB-X中执行逻辑层算子的组件。对于简单的点查SQL,往往可以整体下推存储层MySQL执行,因而感觉不到执行器的存在,MySQL的结果经过简单的解包封包又被回传给用户。但是对于较复杂的SQL,往往无法将SQL中的算子全部下推,这时候就需要PolarDB-X执行器执行无法下推的计算。
例如,对于如下查询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的执行计划如下:
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执行器进行计算,得到最终用户SQL需要的结果。
Volcano执行模型
PolarDB-X和很多数据库一样采用Volcano执行模型。所有算子都定义了open()
、next()
等接口,算子根据执行计划组合成一棵算子树,上层算子通过调用下层算子的next()
接口的取出结果,完成该算子的计算。最终顶层算子产生用户需要的结果并返回给客户端。
下面的例子中,假设HashJoin
算子已经完成构建哈希表。当上层的Project算子请求数据时,HashJoin
首先向下层Gather
请求一批数据,然后查表得到JOIN结果,再返回给Project算子。
某些情况下,算子需要将数据全部读取并缓存在内存中,该过程被称为物化,例如,HashJoin算子需要读取内表的全部数据,并在内存中构建出哈希表。其他类似的算子还有HashAgg(聚合)、MemSort(排序)等。
由于内存资源是有限的,如果物化的数据量超出单条查询限制,或者使用的总内存超出PolarDB-X节点内存限制,将会引起内存不足(OUT_OF_MEMORY
)报错。
并行查询
并行查询(Parallel Query) 指利用多线程并行执行用户的复杂查询。
说明 该功能仅在PolarDB-X标准版及企业版上提供,入门版由于硬件规格限制,不提供该项功能。
并行查询的执行计划相比原来有所改动。例如,还是以上面的查询为例,它的并行执行计划如下所示:
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 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结果:
上图中,红色方框对应左边的LogicalView的下推查询,蓝色方框对应右边LogicalView的下推查询。