SubQuery优化

https://zhuanlan.zhihu.com/p/60380557

 

子查询，分两种状况，

对于在From中的，称为‘derived table’，这种场景比较简单

对于在select，where中的，scalar表达式，这是主要要考虑的对象，由于这种状况cross了relational和scalar的处理

 

子查询，最关键的区分，是关联子查询（Correlated Subquery）和非关联子查询（Non-correlated Subquery）

关联子查询，子查询的执行，子查询参数，依赖于外层父查询输出的属性

非关联子查询，子查询的执行，不依赖于外层父查询的任何属性值，这样子查询具备独立性，可独自求解

非关联子查询的优化很是简单，由于能够独立求解，那就先求出并物化，带入父查询join便可

因此子查询优化的核心就是，去关联，de-correlate

 

从子查询返回的数据分类，

标量（Scalar-valued）子查询: 输出就是一个标量
存在性检测（Existential Test）子查询：特指 EXISTS 的子查询，返回一个布尔值
集合比较（Quantified Comparision）子查询：特指 IN、SOME、ANY 的查询，返回一个布尔值或Null，可能返回null

 

 

 

 

先看几篇基础的论文，

Microsoft的论文，

Parameterized Queries and Nesting Equivalencies - C Galindo-Legaria
Orthogonal Optimization of Subqueries and Aggregation - C Galindo-Legaria, M Joshi
Execution Strategies for SQL Subqueries - Mostafa Elhemali

 

Parameterized Queries and Nesting Equivalencies 

这篇论文核心，是提出Apply算子，而且如何经过各类规则，把Apply算子转换为普通的join

例子中一个，标量子查询的例子，

对于关联子查询，语义其实就是，对于outer表的每一行数据，都执行一遍子查询，这个很是相似，function programming里面的Apply算子

因此这里就是是用Apply算子来，描述这种关联性

Apply算子的定义，

对于关系表R，其中每一个r，带入E，由于E是个参数化expression，把结果求并集

这里其实对于R是要求Distinct，由于R中的r可能会重复，因此通常会加上一个算子去重

中间的A❌就表明apply算子，这里和普通join同样，根据对于E返回的Empty的处理，分为，

看上面的例子，用Apply算子的结果，

 

若是outer表足够小，而且有比较好的indexes的状况下，Correlatied执行效率也很好的

可是大多数通常状况下，Apply执行明显效率很低，因此要基于Apply算子去进行优化，Apply算子是个中间状态，比原来的形式更加容易使用关系代数优化

Apply的优化就，SubQuery unnesting或correlation removel，就是把Apply算子转换为regular join的过程，

下面看个最直接的例子，

 

Orthogonal Optimization of Subqueries and Aggregation

先看个例子，

标量，关联子查询的例子

最直接的方法，直接Correlated execution，不必定低效，若是Outer表很小，而且有适当的索引

80年代，提出过一些优化的方案，

好比，先Outerjoin，再aggregate的方案

 或者，先Aggregate，再Join

可是这些方案，不是系统的方法论，不一样的状况下，须要分析并使用不一样的方法，

本文的方式是，把这些方法分解成，orthogonal, reusable primitives，用的时候能够组合起来，用cost-estimation的方式，评估到底使用哪些primitives

能够看出，分为图中的几步，下面分别解释一下各个步骤，

 

Algebrize

用Apply算子来抽象和替换parameterized execution of subexpressions

Apply算子的好处在于，去除relation和scalar节点间的mutual recursion

例子，左图，查询中有，scalar表达式，scalar表达式中又有子查询，因此执行的时候，须要反复在查询计划执行器和表达式执行器之间不断切换，效率很低，并且隔着scalar表达式，无法用关系代数进行优化或reorder

因此用Apply算子变换到右图，把子查询从scalar表达式中remove掉，放到关系代数树中

这里用标量子查询为例，可是其余的子查询也是同样的

这步只是对过程作了抽象，但实际上并无改变执行计划

 

这里还提到一种，SegmentApply算子

能够认为是batch版本的Apply算子

由于咱们能够用column A对R进行分组，对于每一组，table-valued，去调用E

a就是Distinct(A)

 

Remove Correlation

也就是remove apply

作法， 不断下推Apply，直到不关联了，转化为regular join

The process consists of pushing down Apply in the operator tree, towards the leaves, until the right child of Apply is no longer parameterized off the left child.

可使用的转换rules，

(1) (2)，左右不相干的状况下，apply能够直接转化成join

后面全部rules的目的，就是要转换成知足 (1) (2)

这里，(8)(9)，比较难理解

首先，先看两个概念，

Vector Aggregation，GroupBY聚合，group by A，aggregate with Function F
关键，表为空的时候，返回也是empty

Scalar Aggregation，全局聚合，不指定A，aggregate with Function F
关键，总会有一行返回值，不会为empty；而且返回值和Aggregate函数相关，若是是sum，返回null，若是是count，返回0

(8)中，columns(R)表示join key，把group by提到外面后，须要先按照join key作group by

(8)和(9)的差异就是，(9)是Scalar Aggregation，因此返回值对于empty会出现null，因此F’须要特殊处理，用非null的column
再者Scalar Aggre提到外面后变成Vector Aggre (group by join key)

下面看个例子，仍然是上面的SQL

首先，为何是Scalar Aggre，由于这里Group by join key，对于Apply算子，group by每次只apply到一个customer，因此是Scalar Aggre
用(9)，把Scalar Aggre提出来，变成Vector Aggre
提出GroupBY后，剩下的能够直接应用(2)消除Apply
最后，因为最终的aggre结果须要非null，因此能够简化成inner join

 

Reorder Groupby

Groupby能够和其余算子进行交换，好比filter，join等

GroupBy的Reorder是否会下降cost，这个须要cost model去判断，好比先GroupBY，后Join，仍是先Join，后GroupBy

GroupBy和Filter Reorder

条件，if and only if all the columns used in the filter are functionally determined by the grouping columns in the input relation

过滤的columns，由GroupBy columns决定

GroupBy和Join Reorder

GroupBy pushdown 条件，

GroupBy Pullup的条件，

 

Segmented Execution

以TPCH-17为例，

完成去关联后的计划以下， 

这个计划的问题是，咱们其实不用对全部Lineitem的rows都作这样的聚合过滤，其实只是须要对过滤后的PartKey对应的lineitem作

因此这里的方法是，把LineItem按照partkey进行group，每一个group叫作Segment，而后对Segment执行子查询

叫作SegmentApply，

对于SegmentApply，下面要作的是，按照Part的条件过滤Segments，也就是要把外部的条件Push down到SegmentApply里面，

push down的条件是，segment的完整性，join的条件以segment为条件进行过滤，而不会过滤掉部分row

 完成pushdown的结果以下，在SegmentApply以前，先会对LineItem作join进行过滤掉不须要的segment