厦门网站建设工程,汽车网站正在建设中模板,阿里巴巴官网下载app,网站做定向的作用PolarDB-X接收到一条SQL后的执行过程大致如下#xff1a;语法解析器(Parser)将SQL文本解析成抽象语法树(AST)。语法树被转化成基于关系代数的逻辑计划。优化器(Optimizer)对逻辑计划进行优化得到物理计划。执行器(Executor)执行该计划#xff0c;得到查询结果并返回给用户。本…PolarDB-X接收到一条SQL后的执行过程大致如下语法解析器(Parser)将SQL文本解析成抽象语法树(AST)。语法树被转化成基于关系代数的逻辑计划。优化器(Optimizer)对逻辑计划进行优化得到物理计划。执行器(Executor)执行该计划得到查询结果并返回给用户。本章将会介绍查询优化器的基本原理包含如下几个方面关系代数算子。查询改写(RBO阶段)。查询计划枚举(CBO阶段)。关系代数算子一条SQL查询在数据库系统中通常被表示为一棵关系代数算子组成的树有如下场景的算子Project用于描述SQL中的SELECT列包括函数计算。FIlter用于描述SQL中的WHERE条件。JOIN用于描述SQL中的JOIN其对应的物理算子有HashJoin、 BKAJoin、Nested-Loop Join、SortMergeJoin。Agg用于描述SQL中的Group By及聚合函数其对应的物理算子有HashAgg、SortAgg。Sort用于描述SQL中的Order By及Limit其对应的物理算子有TopN、MemSort。LogicalView用于描述PolarDB-X下发至RDS MySQL或PolarDB MySQL的SQL其内部可能包含一个或多个逻辑算子。Gather代表从多个数据流汇集数据的操作通常出现在LogicalView之上(若开启并行执行则并行优化步骤会将其上拉)。例如对于如下查询SQL(修改自TPC-H Query 3)SELECT l_orderkey,sum(l_extendedprice*(1-l_discount))AS revenueFROM CUSTOMER,ORDERS,LINEITEMWHERE c_mktsegmentAUTOMOBILEandc_custkeyo_custkeyandl_orderkeyo_orderkeyando_orderdateandl_shipdate1995-03-13GROUP BY l_orderkey;通过如下EXPLAIN命令看到PolarDB-X的执行计划HashAgg(groupl_orderkey,revenueSUM(*))HashJoin(conditiono_custkey c_custkey,typeinner)Gather(concurrenttrue)LogicalView(tablesORDERS_[0-7],LINEITEM_[0-7],shardCount8,sqlSELECT 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(concurrenttrue)LogicalView(tablesCUSTOMER_[0-7],shardCount8,sqlSELECT c_custkey FROM CUSTOMER AS CUSTOMER WHERE (c_mktsegment ?))用树状图表示如下左边的LogicalView实际包含了ORDERS和LINEITEM两张表的JOIN。EXPLAIN结果中LogicalView的SQL属性也体现了这一点。查询改写(RBO)查询改写(SQL Rewrite)阶段输入为逻辑执行计划输出为逻辑执行计划。这一步主要应用一些启发式规则是基于规则的优化器(Rule-Based Optimizer简称RBO)所以也常被称为RBO阶段。查询改写这一步的主要有如下功能子查询去关联化(Subquery Unnesting)子查询去关联化是将含有关联项的子查询(关联子查询)表示为SemiJoin或类似的算子便于后续的各种优化处理例如下推到MySQL或在PolarDB-X层选择某种算法执行。在如下例子中IN子查询转化为SemiJoin算子并最终转化成SemiHashJoin物理算子由PolarDB-X进行执行explainselectidfromt1whereidin(selectidfromt2wheret2.namehello);SemiHashJoin(conditionid id,typesemi)Gather(concurrenttrue)LogicalView(tablest1,shardCount2,sqlSELECT id FROM t1 AS t1)Gather(concurrenttrue)LogicalView(tablest2_[0-3],shardCount4,sqlSELECT id FROM t2 AS t2 WHERE (name ?))算子下推算子下推是非常关键的一步PolarDB-X内置了如下算子的下推优化规则谓词下推或列裁剪将Filter及Project算子下推至MySQL执行过滤掉不需要的行和列。JOIN Clustering将JOIN按照拆分方式及拆分键相等进行重排和聚簇方便下一步的JOIN下。JOIN下推对于符合条件的JOIN将其下推至MySQL执行。Agg下推将聚合(Agg)拆分为FinalAgg和LocalAgg两个阶段并将LocalAgg下推至MySQL。Sort下推将排序(Sort)拆分为MergeSort和LocalSort两个阶段并将LocalSort下推至MySQL。更多关于查询下推的信息请参见查询改写与下推。查询计划枚举(CBO)经过查询改写阶段的逻辑执行计划会被输入到查询计划枚举(Plan Enumerator)输出一个最终的物理执行计划。查询计划枚举在多个可行的查询计划中根据预先定义的代价模型选择出代价最低的一个。与查询改写阶段不同在查询计划枚举中规则可能产生更好的执行计划也可能产生更差的执行计划我们会根据前后的代价相比较来选择出较优的那个因此这也被称为基于代价的优化(Cost-based Optimizer简称CBO)。其核心组件有以下几个部分统计信息(Statistics)基数估计(Cardinality Estimation)转化规则(Transform Rules)代价模型(Cost Model)计划空间搜索引擎(Plan Space Search Engine)逻辑上CBO的过程包括如下几个步骤搜索引擎利用转化规则对输入的逻辑执行计划进行变换构造出物理执行计划的搜索空间。之后利用代价模型对搜索空间中的每一个执行计划进行代价估计选出代价最低的物理执行计划。而代价估计的过程离不开基数估计它利用各个表、列的统计信息估算出各算子的输入行数、选择率等信息提供给算子的代价模型从而估算出查询计划的代价。
