为什么需要query optimization

因为SQL是声明式的
其实直到现在，任然有两种流派，一种是数据库帮助优化query还有一种是自己写算子，比如flink

数据库优化方式，也就是写SQL

• 启发式：只需要查看元数据，不需要查看真正的数据
• 基于代价的搜索：类似于回溯，需要计算代价函数
  

query的执行架构

• 将query 语句重写，一些小的优化
• 将query 解析成语法树
• 将语法树中的表名,列名之类的转换成实际物理地址(Internal ID)
• Logical Plan是将原来的语法树转变成标准的树，这里叫正规化比如说是树转化为二叉树
• 将初始的未优化的Logical plan传入optimizer
• 根据是启发式还是代价式的优化，optimizer还需要其他数据，比如启发式需要元数据，代价式需要代价模型
• 最后生成Physical Plan，也就是真实的算子
  

LOGICAL VS. PHYSICAL PLANS

optimizer会将logical plan转化为physical plan，比如 inner join转化为nested loop，hash join或者merge join

Relational Algebra Equivalence

这个Relational Algebra Equivalence是做优化的基本原理

谓词推到与投影推到

删除不必要的谓词

Heuristics / Rules 启发式/规则优化

启发式优化并没有使用代价模型，不能够比较plan之间的好坏，不需要实现理解数据库的内容

LOGICAL QUERY OPTIMIZATION

SPLIT CONJUNCTIVE PREDICATES

PREDICATE PUSHDOWN

REPL ACE CARTESIAN PRODUCTS

将所有的笛卡尔积通过join predicate转换为join语句

PROJECTION PUSHDOWN

NESTED SUB-QUERIES

解构子查询

将子查询与父查询写成一个查询

分离子查询，先执行子查询得到一个临时表

EXPRESSION REWRITING

？

Cost-based Search

Cost Estimation

代价模型只在内部有效
代价模型的组成部分：

如果使用了选择基数，那么就是假设数据是均匀的

这里sel类似于概率，在table满足predicate P的tuple的数量占所有tuple的比例

select cardinality所做的一些假设
#是指数量
列之间常常不是独立的，比如这里的只有制造商Honda能够制造车品牌Accord，那么这两个列是相关的

一般相关性强的列，可以先将它们join，再计算selectivity

un-uinform的数据估计

histogram

对于不均匀的数据，可以用一些方法统计数据
比如EQUI-WIDTH HISTOGRAM,EQUI-DEPTH HISTOGRAMS
对于EQUI-DEPTH HISTOGRAMS需要去估计一个数据的频率，比如5，那就是1/5的概率出现在第一桶中，第一个桶子的数出现的概率为1/4，那么5的数据频率就是1/20

sketch

通过概率来估计数据的存在可能性

sampling

抽样

Plan Enumeration

通过selectivity of predicates，可以估计每一个算子的传递数据的数量，这样一来就可以计算query plan的代价
在基于规则的重写plan之后，也就是heuristic优化，再之后通过代价模型枚举所有的query plan，在枚举完所有plan或者枚举了一定的时限之后，选出最佳的plan

对于不同类型的query plan，采取不同的优化策略

Single-Relation Query Plans

一般只用启发式就好了
sargable指可以按照参数查找，就是指存在index去查找

Multi-Relation Query Plans

左深树能够适应管道流式plan？右边两种plan需要暂存join结果

一般使用dp去枚举

标签：15,14,join,优化,Optimization,plan,启发式,query,代价
来源： https://www.cnblogs.com/mlmz/p/15973106.html