PolarDB · 最佳实践 · 并行查询优化器的应用实践.pdf

张鹏

4页

2次

2024-10-28

免费下载

PolarDB · 最佳实践 · 并行查询优化器的应用实践

PolarDB MySQL8.0重磅推出了并行查询引擎，充分利用硬件多核多CPU的优势，基于COST自动选择并行查询

计划，显著提升了查询性能，查询耗时呈>指数级下降，体现了自研PolarDB数据库极高的性价比。下面我们以

TPCH的query-10为例，详细解析并行查询引擎对复杂查询的优化能力，为用户指引一条并行执行的性能高速公

路。 Q10的SQL如下所示:

SELECT

c_custkey, c_name, sum(l_extendedprice * (1 - l_discount)) as revenue,

c_acctbal, n_name, c_address, c_phone, c_comment

FROM

customer, orders, lineitem, nation

WHERE

c_custkey = o_custkey

and l_orderkey = o_orderkey

and o_orderdate >= date '1993-05-01'

and o_orderdate < date '1993-05-01' + interval '3' month

and l_returnflag = 'R'

and c_nationkey = n_nationkey

GROUP BY

c_custkey, c_name, c_acctbal, c_phone, n_name, c_address, c_comment

ORDER BY

revenue desc

LIMIT 20;

从SQL语句中可以看出，这个查询首先是4个表的JOIN，然后进行GROUP BY分组聚合操作，最后对聚合操作的

结果进行排序，并选择前20条输出。

串行查询测试

Q10是分析场景下最常见的操作，先JOIN，再聚合、最后排序输出。如果不开启并行查询开关，它的串行执行

计划如下所示：

这个计划很简单，选择Orders表做为驱动表，然后做Nest loop join，当JOIN完成后，利用临时表来做聚合操

作，最后进行排序。其中Orders表很大，即使Orders表上有条件可以帮助过滤大部分的数据，最终预估Orders

表仍有大约110万行数据，最终执行时也比较长，大约需要16.29秒。

并行查询测试

PolarDB从8.0.1.0开始就支持并行查询，并且在8.0.2.0又做了全新的优化升级，接下来我们分别对2个版本进行

并行查询的测试。首先测试8.0.1.0版本，在8.0.1.0中开启并行查询，只需设置一个session级的参数

max_parallel_degree，即最大并行度，简称DOP，用来设置执行>并行任务的最大worker线程数：例:

set max_parallel_degree=32;

表示设置最大并行度DOP为32，根据实际查询的数据量，运行时的并行度可能小于32，但最大为32。并行查询

计划如下所示:

与之前的串行计划最大的不同在于计划上多了一行名为gather的计划，它表示汇集多个worker线程并行执行后

的结果。同时在Orders表的Extra信息>也多了一些额外信息Parallel scan (32 workers)，这表示Orders表将会

执行并行扫描，同时有32个worker线程分别扫描Orders表的一部分数据，每个worker线程只需扫描大约3.4万

行数据，然后并行完成JOIN，最后由Gather汇集所有JOIN的结果，执行聚合操作，完成排序后将结果返回。

查询总共大约3.46秒，相比串行性能已经有了明显提升，提升了大约5倍的性能。相信你已经感叹并行查询的威

力，但是不要着急，后面的8.0.2.0的测试会给你带来更大的惊喜。

并行查询测试(8.0.2.0版本)

下面用8.0.2.0版本进行测试，在8.0.2.0中，对并行度做了重新定义，并行度DOP指的是活跃并行度，所谓活跃

并行度指同时执行的worker线程数，>后面会根据示例再详细解释活跃并行度的概念。测试的并行度仍然设置

为32，则并行计划如下图所示:

与8.0.1.0产生的并行计划相比，我们发现又多出了一行名为repartition的计划，它表示JOIN后的数据要通过

repartition将数据根据group by的column重新分区，然后各个分区的数据在不同的worker上并行执行聚合操

of 4

免费下载

polardb

关注

评论