[CMU 15-445] 14 查询计划生成与优化 -Ⅰ

1. Overview

SQL作为声明式语句，不透露查询的具体实现细节。DBMS首先解析SQL语句得到逻辑计划，随后优化逻辑计划，最后为逻辑计划中的每个算子选择效率最高的物理执行方式，即物理查询计划。逻辑计划优化和物理计划优化统称为查询优化，决定了SQL语句的最终执行效率。

最早的查询优化工作起源于70年代System R，其中的许多概念和技术沿用至今

查询优化的方法总体可分为两类，分别是基于规则的启发式方法和基于查询代价预估的方法。第一种方法最多只需要检查catalog目录粗粒度地避免查询中的无用工作；第二种则需要检查实际数据大小、索引等，对每种执行方式代价进行预估后选择代价最小查询计划的去执行。

围绕查询优化，本节主要介绍关系代数等价、查询计划估计、查询计划枚举以及子查询优化。

查询优化的整体流程如下图所示，主要有SQL重写（可选）、SQL解析、字段-Internal ID映射、根据schema重写查询树（可选）、逻辑/物理计划优化几个步骤。

为了生成开销最低的物理查询计划，查询优化器需要根据逻辑计划以及当前物理存储情况（tuple规模、索引大小）生成。

查询优化是一个NP-Hard问题，可选的执行可能很多，导致搜索范围很广，查询优化器需要在很短的时间内寻找到相对最优的解法。

2. Relational Algebra Equivalences

若两个关系代数表达式所产生的元组相同，那么这两个关系表达式就是等价的。DBMS系统最开始可以不通过代价估算来优化查询计划，即首先重写低效率的SQL语句。

例如下面的例子，将过滤算子往查询树的根部移动，提前过滤掉部分tuple，降低后续连接算子的代价。

对于SELECT算子，优化过程中尽可能早的过滤掉不满足条件的tuple，提高后续算子的运行效率。同时，简化也要注意精简表达式。

投影算子与查询算子类似，尽可能提前执行投影算子。

其他例子，例如对于结果不变的判断语句（恒定TRUE or FALSE），避免逐一扫描tuple，优化器直接将判断语句删除。

在下面稍微复杂一点的查询中，处理方式也是一样。

SQL语句避免对相同内容重复查询。

多表间不同的连接顺序也将带来不同处理开销，另外，如何在大范围搜索空间中快速确定相对最优的连接顺序也是优化器需要解决的问题。

3. Cost Estimation

查询优化过程中需要预估每种查询计划的开销，最终选择开销最低的执行方式。预估代价时需要考虑的点包括硬件资源占用、处理的tuple数目等。

DBMS会建立数据表、索引等内容的统计信息（放在catalog中），用于预估开销时候使用。

关注我的微信订阅号，交流数据管理与分布式系统相关技术：