更新时间:2020-08-15 15:53
PolarDB-X接收到一条SQL后的执行过程大致如下:
本章将会介绍查询优化器的基本原理,包含如下几个方面:
一条SQL查询在数据库系统中通常被表示为一棵关系代数算子组成的树,有如下场景的算子:
例如,对于如下查询SQL(修改自TPC-H Query 3):
SELECT l_orderkey, sum(l_extendedprice *(1 - l_discount)) AS revenue
FROM CUSTOMER, ORDERS, LINEITEM
WHERE c_mktsegment = 'AUTOMOBILE'
and c_custkey = o_custkey
and l_orderkey = o_orderkey
and o_orderdate < '1995-03-13'
and l_shipdate > '1995-03-13'
GROUP BY l_orderkey;
通过如下EXPLAIN命令看到PolarDB-X的执行计划:
HashAgg(group="l_orderkey", revenue="SUM(*)")
HashJoin(condition="o_custkey = c_custkey", type="inner")
Gather(concurrent=true)
LogicalView(tables="ORDERS_[0-7],LINEITEM_[0-7]", shardCount=8, sql="SELECT `ORDERS`.`o_custkey`, `LINEITEM`.`l_orderkey`, (`LINEITEM`.`l_extendedprice` * (? - `LINEITEM`.`l_discount`)) AS `x` FROM `ORDERS` AS `ORDERS` INNER JOIN `LINEITEM` AS `LINEITEM` ON (((`ORDERS`.`o_orderkey` = `LINEITEM`.`l_orderkey`) AND (`ORDERS`.`o_orderdate` < ?)) AND (`LINEITEM`.`l_shipdate` > ?))")
Gather(concurrent=true)
LogicalView(tables="CUSTOMER_[0-7]", shardCount=8, sql="SELECT `c_custkey` FROM `CUSTOMER` AS `CUSTOMER` WHERE (`c_mktsegment` = ?)")
用树状图表示如下:
左边的LogicalView实际包含了ORDERS和LINEITEM两张表的JOIN。EXPLAIN结果中LogicalView的SQL属性也体现了这一点。
查询改写(SQL Rewrite)阶段输入为逻辑执行计划,输出为逻辑执行计划。这一步主要应用一些启发式规则,是基于规则的优化器(Rule-Based Optimizer,简称RBO),所以也常被称为RBO阶段。
查询改写这一步的主要有如下功能:
> explain select id from t1 where id in (select id from t2 where t2.name = 'hello');
SemiHashJoin(condition="id = id", type="semi")
Gather(concurrent=true)
LogicalView(tables="t1", shardCount=2, sql="SELECT `id` FROM `t1` AS `t1`")
Gather(concurrent=true)
LogicalView(tables="t2_[0-3]", shardCount=4, sql="SELECT `id` FROM `t2` AS `t2` WHERE (`name` = ?)")
更多关于查询下推的信息,请参见查询改写与下推。
经过查询改写阶段的逻辑执行计划会被输入到查询计划枚举(Plan Enumerator),输出一个最终的物理执行计划。
查询计划枚举在多个可行的查询计划中,根据预先定义的代价模型,选择出代价最低的一个。与查询改写阶段不同,在查询计划枚举中,规则可能产生更好的执行计划,也可能产生更差的执行计划,我们会根据前后的代价相比较来选择出较优的那个,因此这也被称为基于代价的优化(Cost-based Optimizer,简称CBO)。
其核心组件有以下几个部分:
逻辑上,CBO的过程包括如下几个步骤:
在文档使用中是否遇到以下问题
更多建议
匿名提交