CMU Database Systems - Query Optimization

查询优化应该是数据库领域最难的topic

当前查询优化，主要有两种思路，

Rules-based，基于先验知识，用if-else把优化逻辑写死

Cost-based，试图去评估各个查询计划的cost，选取cost比较小的

一个sql query的处理流程，

先是Parser，生成抽象语法树ast，Binder会去做元数据对应，把parse出来的name对应到数据库中的结构，表，字段等

然后Rewriter就是Rules-based的改写，而Optimizer是cost-based的优化

Relational Algebra Equivalences

做查询优化的前提是，查询的结果是不能变的

无论你查询怎么优化，最终得到的结果是一样的，那么就称他们是，关系代数等价

对于不同的operator，有些通用的优化rules，

这里给些例子，

Selections

对于selection，尽量下推，谓词下推，尽量早做

Projections

projection也是应该尽早去做，不需要的字段就根本不用读出来

Joins

对于Join是符合交换律和结合律的，但是对于多表join，你需要尝试的可能性是非常多的

Cost Estimation

cost-based的查询优化，关键就是要能够知道cost

如何预估cost是很复杂的问题

当前的思路，就是我们会事先对数据表，列，索引做些统计，并存储到catalog里面，然后后面就根据这些统计数据来预估cost

主要的统计数据，包含两项，行数和每一列的distinct values的个数

然后有个概念，selection cardinality，两个相除，就是平均每个value多少行

这里的假设是数据是均匀分布，很naive

有了这些概念，我们就可以来定义复杂谓词，操作，的selectivity，筛选率

Equality，Range

Equality的定义有些confuse，SC(P)，SC(age=2)啥意思？

其实以range的逻辑看，这里就应该是，A列一共有5个值，当前Equality只取其中一个，所以五分之一，就这么简单

Conjunction和Disjunction

Join，对于join，这个cost算的很粗糙，比如R表中的行数 * 每行在S中的cardinality

平均分布问题

当前算cost，都是假设平均分布，这个明显是很不合理的

但是如果对于每个value都去记录一个统计，明显不可行，太多了

所以有如下几种近似方法，

一种，每个value bucket都去统计太多，那就分组，这样每个组记录一个统计，组内仍然假设平均分布

分组可以有两种方式，第一个是固定bucket数，或者固定组内bucket统计和差不多，叫等宽

还有种更直接的方式，sampling

Query Optimization

上面说的cost estimation的方法都很naive，但是如果我们能准确的预估执行计划的cost，那么如何真正的做查询优化？

这里分为三种情况，

Single Relation，Multiple relations， Nested Sub-queries

Single Relation，比较简单，单关系表的查询

所以关键就是选择合理的access method，是顺序扫描，还是用各种索引

这里有个概念，sargable，数据库专有概念，意思是查询或执行计划可以用索引来优化的

OLTP的查询往往都是sargable的，所以通过简单的启发式的方式就可以找到优化方法

Multiple relations

多关系表join就比较复杂了

除了要选择各个表的access method

还需要选择各个表的join顺序和join算法

其中选择join顺序是个cost很高的事情，因为可能性和search space会比较的大

这里介绍IBM R的方法，它把join顺序简化成，只考虑Left-deep tree（右图最左边这个）

这样search space会大幅缩小，另外特意选择left-deep tree的原因是，这种join结构，比较容易pipeline执行，比如下图，a b的join结果直接可以用于和c join，当中间结果不是很大的时候，不需要不断地的把结果写到磁盘

对于Multiple relations，可以尝试用动态规划来选择best plan

更为形象的例子来说明如何逐步筛选plan

第一步是选择join的顺序，可以首先把明显低效的，比如做cross-products的Prune掉

然后根据cost model找出best的plan

第二步是选择join算法，这里有Nested Loop和Hash Join

第三步是选择access method，

Nested Sub-queries

第三种更为复杂一些，在有子 SQL 的时候，如何优化？

有两种方式，一种是通过rewrite，把嵌套的子语句flatten掉，如右图的例子

另一种方法，是decompose，如下面的例子

子句是要获取最大的rating，这个反复去执行一定是低效的，所以，干脆把这个语句拿出来单独执行，结果放在临时表，然后执行主语句的时候把值填回去