比特派钱包app下载|rbo

首页
rbo

比特派钱包app下载|rbo

作者：比特派钱包app下载

2024-03-07 20:49:31

简单了解CBO、RBO、HBO - 知乎

简单了解CBO、RBO、HBO - 知乎切换模式写文章登录/注册简单了解CBO、RBO、HBO大数据启示录RBO基于规则的优化器指的是不需要额外的信息，通过用户下发的SQL语句进行的优化，主要通过改下SQL，比如SQL子句的前后执行顺序等。比较常见的优化包括谓语下推、字段过滤下推、常量折叠、索引选择、Join优化等等。 RBO对数据不敏感，在表大小固定的情况下，无论中间结果数据怎么变化，只要SQL保持不变，生成的执行计划就都是固定的CBO基于代价的优化器，根据收集的统计信息来计算每种执行方式的代价，进而选择最优的执行方式。引人了重新排序 Join（JoinReorder）和自动MapJoin（AutoMapJoin ）优化规则等，同时基于 Volcano 模型的优化器会尽最大的搜索宽度来获取最优计划可以设置规则白名单（使用哪些优化规则）、黑名单（关闭哪些优化规则）Optimizer 会提供谓词下推（ PredicatePushDown ）优化，主要目的是尽量早地进行谓词过滤，以减少后续操作的数据量，提高性能。但需要注意的是：UDF：对于UDF是否下推，优化器做了限制，不会任意下推这种带有用户意图的函数，主要是因为不同用户书写的函数含义不一样，不可以一概而论。不确定函数：对于不确定函数，优化器也不会任意下推，比如 sample 函数，如果用户将其写在 where 子句中，同时语句存在Join ，则优化器是不会下推到 TableScan 的隐式类型转换：书写 SQL 语句时，应尽量避免 Join Key 存在隐式类型转换。CBO优化器通过给CPU、内存、NETWORK赋予代价，来指导生成更优的执行计划 CBO组成① Meta Manager：优化器在选择优化策略时会使用一些元数据，如数据表元数据，分区元数据，统计信息元数据等。

② Statistics：为优化器提供准确的统计信息，进行优化策略的选择

③ Rule Set：每一条优化规则都是特定场景下的优化点，优化器根据代价模型选择启用哪些规则。规则分为：

+ Substitute Rule：优化了一定好的规则

+ Explore Rule：优化后需要考虑各种因素的规则

+ Build Rule：优化后不能再次优化的规则

④ Volcano Planner Core：把所有信息统一处理，根据代价模型，涉及代价最小的方案

代价计算：发生在产生的新节点注册阶段，计算规则如下：+ 如果代价不存在或者子节点的代价还没计算，则忽略

+ 如果有代价，则将本身的代价和子节点的代价相加，若小于目前的最优策略，则认为当前节点是最优的。还会对其父节点的代价进行迭代计算，进而估算整条链路的代价

HBO（History-Based Optimizer，基于历史的优化器）在任务稳定的情况下，可以考虑基于任务的历史执行情况进行资源评估，即采用HBO提高 CPU 利用率

提高内存利用率

提高 Instance 并发数

降低执行时长

针对大促这类数据量暴涨的场景， HBO 也增加了根据数据量动态调整 Instance 数的功能，主要依据 Map 的数据量增长情况进行调整。HBO 分配资源方法：① 核心思想：基础资源评估+加权资源评估

② 基础资源评估：对于map任务的数量根据用户提交任务的数据量和每个map任务期望执行的数据量来估算；对于reduce任务个数由map任务的输入数据量估算或者根据近几天map任务对reduce任务的输出数据量的平均值进行估算。

③ 加权资源评估：通过当前任务近期执行速度与任务预期执行速度作比较，如果小于预期则等比例添加资源，估算出最终的任务数量

参考资料：https://www.6aiq.com/article/1670429368683

https://zhuanlan.zhihu.com/p/627340125

常见RBO优化点各种表达式的重写和化简

Cast 消除

谓词化简

公共谓词提取

列裁剪

Shuffle 列裁剪（确保任何多余的列不要参与网络传输）

谓词下推

等价谓词推导（常量传播）

Outer Join 转 Inner Join

Limit Merge

Limit 下推

聚合 Merge

Intersect Reorder

常量折叠

公共表达式复用

子查询改写

Lateral Join 化简

Empty Node 优化

Empty Union, Intersect, Except 裁剪

In 转 Semi Join 或者 Inner Join （http://mysql.taobao.org/monthly/2023/01/01/）

聚合算子复用

# 比如对于下面的 SQL:

# SELECT AVG(x), SUM(x) FROM table

#我们可以让 AVG(x) 复用 SUM(x) 的计算结果，减少计算量

Primary Key 相关优化

冗余 Group By 消除

Sum 常量转 Count

Data Skipping

常见CBO优化点多阶段聚合优化

Join 左右表 Reorder

Join 多表 Reorder

Join 分布式执行选择

Shuffle Join

Broadcast Join

Bucket Shuffle Join

Colocate Join

Replication Join

Join 和 Aggregate Runtime Colocate, 避免 Shuffle

CTE 复用

CTE 列裁剪

Agg 上拉

Agg 下推 Join

Agg 下推 GroupingSets

窗口下推 Group By

算子融合

物化视图选择与改写

利用基数信息进行优化

HBO常见优化点表元数据本地缓存（表来源、表定义、分区个数、分区信息、文件列表、统计信息等）

hdfs文件缓存

sql执行记录结果集落表（sql提交失败、运行失败、运行成功）

保存历史sql执行时，预估内存值和实际消耗内存值

DataCache

多表物化视图

发布于 2023-06-29 16:33・IP 属地北京美剧HBO自制美食赞同添加评论分享喜欢收藏申请

SQL优化器-RBO与CBO分别是什么 - JasonCeng - 博客园

会员

周边

新闻

博问

AI培训

云市场

所有博客

当前博客

我的博客

我的园子

账号设置

简洁模式 ...

退出登录

JasonCeng's Blog

博客园

首页

联系

管理

SQL优化器-RBO与CBO分别是什么

数据库系统是软件领域的重要基础设施，而SQL优化器又是其重要组成部分。本文主要是对两个查询优化器，RBO: Rule-Based Optimization“基于规则的优化器”和CBO: Cost-Based Optimization“基于代价的优化器”进行概述性介绍。

数据库系统发展历史

数据库系统产生于20世纪60年代中期，至今有近50多年的历史，其发展经历了三代演变，造就了四位图灵奖得主，发展成为一门计算机基础学科，带动了一个巨大的软件产业。

数据库系统是操作系统之上最重要的基础设施之一，被称为软件产业的常青树，特别是它所支撑起来的大数据、人工智能应用，更是发展迅猛。

面对发展快速的数据库领域，以及人类所拥有的数据量爆发式增长，如何对海量数据进行管理、分析、挖掘便变得尤为重要。SQL优化器正是为了解决以上问题而诞生的。

查询优化器简介

SQL优化器，其中最重要的一个组件是查询优化器，是数据库系统的重要组成部分。特别是对于现代大数据系统，执行计划的搜索空间异常庞大，研究人员研究了许多方法对执行计划空间进行裁剪，以减少搜索空间的代价。

在当今数据库系统领域，查询优化器可以说是必备组件，不管是关系型数据库系统Oracle、MySQL，流处理领域的Flink、Storm，批处理领域的Hive、Spark SQL，还是文本搜索领域的Elasticsearch等，都会内嵌一个查询优化器。

有的数据库系统会采用自研的优化器，而有的则会采用开源的查询优化器插件，比如Apache Calcite就是一个优秀的开源查询优化器插件。而像Oracle数据库的查询优化器，则是Oracle公司自研的一个核心组件，负责解析SQL，其目的是按照一定的原则来获取目标SQL在当前情形下执行的最高效执行路径。

这里拓展一下，关于查询优化器所要解决的核心问题：具有多个连接操作的复杂查询优化。不少学者相继提出了基于左线性树的查询优化算法、基于右线性树的查询优化算法、基于片段式右线性树的查询优化算法、基于浓密树的查询优化算法、基于操作森林的查询优化算法等。这些算法在搜索代价和最终获得的查询计划的效率之间有着不同的权衡。

总的来说，查询优化器在很大程度上决定了一个数据库系统的性能，优化器的作用就好比找到两点之间的最短路径。

RBO(Rule-Based Optimization)

RBO: Rule-Based Optimization也即“基于规则的优化器”，该优化器按照硬编码在数据库中的一系列规则来决定SQL的执行计划。

以Oracle数据库为例，RBO根据Oracle指定的优先顺序规则，对指定的表进行执行计划的选择。比如在规则中：索引的优先级大于全表扫描。

通过Oracle的这个例子我们可以感受到，在RBO中，有着一套严格的使用规则，只要你按照规则去写SQL语句，无论数据表中的内容怎样，也不会影响到你的“执行计划”，也就是说RBO对数据不“敏感”。这就要求开发人员非常了解RBO的各项细则，不熟悉规则的开发人员写出来的SQL性能可能非常差。

但在实际的过程中，数据的量级会严重影响同样SQL的性能，这也是RBO的缺陷所在。毕竟规则是死的，数据是变化的，所以RBO生成的执行计划往往是不可靠的，不是最优的。

CBO(Cost-Based Optimization)

CBO: Cost-Based Optimization也即“基于代价的优化器”，该优化器通过根据优化规则对关系表达式进行转换，生成多个执行计划，然后CBO会通过根据统计信息(Statistics)和代价模型(Cost Model)计算各种可能“执行计划”的“代价”，即COST，从中选用COST最低的执行方案，作为实际运行方案。

CBO依赖数据库对象的统计信息，统计信息的准确与否会影响CBO做出最优的选择。

以Oracle数据库为例，统计信息包括SQL执行路径的I/O、网络资源、CPU的使用情况。

目前各大数据库和大数据计算引擎都倾向于使用CBO，例如从Oracle 10g开始，Oracle已经彻底放弃RBO，转而使用CBO；而Hive在0.14版本中也引入了CBO。

参考文献

[1] 《数据库系统导论》(第5版) 王珊,萨师煊

[2] Oracle SQL优化器简介[https://www.cnblogs.com/mzq123/p/10398701.html]

[3] SQL优化器简介[https://www.cnblogs.com/jixin/p/10500096.html]

[4] 深入浅出Calcite与SQL CBO（Cost-Based Optimizer）优化[https://www.cnblogs.com/listenfwind/p/13192259.html]

[5] SQL优化器原理——查询优化器综述[https://zhuanlan.zhihu.com/p/40478975]

顶

Top

关注

posted @

2020-12-27 22:46

JasonCeng

阅读(8666)

编辑

会员力量，点亮园子希望

刷新页面返回顶部

公告

数据库查询优化器，RBO优化规则介绍及示例-CSDN博客

数据库查询优化器，RBO优化规则介绍及示例

最新推荐文章于 2023-09-30 14:13:10 发布

Aiky哇

最新推荐文章于 2023-09-30 14:13:10 发布

阅读量1.5k

点赞数

分类专栏：

数据库架构

sql查询优化

文章标签：

数据库

sql

mysql

Aiky哇

本文链接：https://blog.csdn.net/qq_35423190/article/details/126388651

版权

数据库架构

同时被 2 个专栏收录

19 篇文章

8 订阅

订阅专栏

sql查询优化

2 篇文章

0 订阅

订阅专栏

数据库查询优化器是针对于sql经过解析后生成的ast表达式树的。

目的是能够降低sql执行计算量，简化计算。

传统数据库中，查询优化是很复杂的，大体上可以分为RBO和CBO，其中CBO的收益性不确定，需要进行代价估算，依赖的数据统计会比较多。而RBO规则优化在不需要了解数据统计信息的前提下，可以明确提升sql执行计划的查询性能。

现在的数据库厂商大多使用的是RBO+CBO或者只用CBO的架构。其实只用CBO更主流一些，TIDB,PolarX都在用，只用cbo搜索空间相对更完整，优化结果更接近全局最优。可扩展性更好，对于新规则的添加更简单。

但是相对的，搜索空间会更大，查询优化过程耗时相对更长。优化结果更依赖搜索算法的好坏。而RBO的查询优化耗时更短，RBO能够带来明确收益，虽然优化结果局部最优，但与全局最优解不会相差很多（在CBO阶段优化了最耗时部分，保证最耗时的规则范围内达到最优）。

我经验有限，这里只是写一下自己了解到的RBO优化规则。这里会大量参考李海翔大佬的《数据库查询优化器的艺术》，tidb的分享文章等等。

逻辑查询优化技术（RBO）的理论基础

子查询优化

子查询的分类

子查询展开

常见的子查询类型优化

mysql和pg的支持项

视图重写优化

等价谓词重写

表达式优化及条件化简

单个表达式的简化

多个表达式之间的简化

pg，mysql，ck支持项

连接相关优化

1.外连接消除

外连接到内连接的转化

外连接消除

2.嵌套连接优化

3.pg，mysql，ck 连接优化

列裁剪优化

算子下推

1.谓词下推

where谓词/having谓词下推场景

join on谓词下推场景

2.TopN和Limit下推（分布式场景）

max/min消除

3.聚合下推

RBO优化框架的问题

逻辑查询优化技术（RBO）的理论基础

常见的优化规则包括：

sql子句局部优化。比如等价谓词重写、谓词化简等。子句之间关联的优化。比如外链接消除、子查询优化等。局部与整体优化。比如or重写成union。形式变化优化。比如通过形式变化进行嵌套连接消除。语义优化。根据完整性约束，sql表达含义等信息来进行语义优化。其他优化。根据一些规则对非SPJ(select,project,join结合的查询)做的其他优化等。

查询优化技术的理论基础是关系代数。关系数据库基于关系代数。

关系模型数据结构就是关系数据库中的二维结构。关系是一种对象，偏于理论。表也是，但偏于工业。表中元数据通常用field或者item来表示。表中行数据通常用tuple，row，record等来表示。对关系进行的运算就是关系运算。运算对象，运算符，运算结果是运算的三大要素。

关系代数运算符包括4类：

传统集合运算符。并（union），交（intrsection），差（difference）,积。专门的关系运算符。select，投影（project）,连接（join）,除（divide）。辅助运算符。算数比较符和逻辑运算符。关系扩展运算符。比如semi join，extend等。

基本关系运算与对应的sql表

关系代数运算符　　　　　　　　　　对应sql语句∪ (UNION)并select * from t1 UNION select * from t2;∩ (INTERSECTION)交select * from t1 where t1.id in (select id from t2);- (DIFFERENCE)差select * from t1 where t1.id not in (select id from t2);× (Cartesian PRODUCT)笛卡尔积　　 select * from t1,t2;π (PROJECT)投影　　　　　　　　　 select id,name from t1;σ (SELECT)选择　　　　　　　　　　select * from t1 where id>10;⋈ (JOIN)链接　　select * from t1 join t2 on t1.id=t2.id;÷ (DIVISION)除select * from t1 where not exists (select t2.id from t2 where t2.id!=t1.id);

子查询优化

子查询的分类

子查询可以出现在sql中的位置如下：

子查询出现位置对优化的影响目标列必须为标量子查询from子句不能有关联子查询。非关联子查询可上拉到父查询。 where子句根据数据类型和操作符不同，对子查询的格式有要求。join on子句 join中同from条件。 on中同where条件，但是具体实现有些许不同。 group by 子句需要和目标列关联（sql规范）。直接写在groupby无实用意义。 having子句同where语句。order by子句无实用意义

子查询的分类如下：

分类方式子查询名称介绍关系对象之间的关系关联子查询依赖外层父查询属性值非关联子查询不依赖外层父查询属性值通过谓词分类[not] in in子查询[not] exists exists子查询其他子查询除上述外的其他子查询语句构成复杂度SPJ子查询选择/投影/连接基础语句组合的子查询GROUP BY子查询SPJ + 聚合组合的子查询其他子查询包含更多其他语句，比如limit ,order by之类的子查询从结果集来分类标量子查询返回结果为单一值列子查询返回结果为单一列，但多行行子查询返回结果为单一行，但多列表子查询返回结果多行多列

子查询展开

常见的子查询优化技术包括：

子查询合并。指产生同样结果集的子查询合并成一个子查询。子查询展开。后面详细说。聚合子查询消除。将子查询转换为不包含聚合函数的子查询。其他。利用窗口函数等来优化子查询。

最重要的是子查询展开。最为常用。实质是将某些子查询重写为多表连接的操作。可以将查询层次减少。

子查询展开有两种形式：

如果子查询中出现了聚集，group by，distinct语句，只能单独求解，无法拉到上层。为SPJ格式的查询，则可以拉到上层。这个也是子查询展开的处理范围。

把子查询上拉，前提是上拉后展开结果不能带来多余的元组（ROW）。所以子查询展开的规则如下：

如果上层查询结果没有重复（唯一键，主键等）。则可以展开子查询，展开后查询的select需要添加distinct。如果上层查询结果包含distinct，可以直接进行子查询展开。如果内层查询结果没有重复，可以展开。

子查询展开步骤如下：

子查询和上层子查询的from语句合并成为一个from语句，修改相应的运行参数。修改子查询的谓词符号。合并子查询和上层查询的where条件。

常见的子查询类型优化

1.in子查询的优化

// in 类型子查询的sql形式

other_expr [not] in (select inner_expr from ... where subquery_where)

// other_expr：外层查询的表达式

// inner_expr：内层查询的表达式

// subquery_where：子查询的过滤条件

// 优化后的sql

exists(

select 1 from ...

where subquery_where and

outer_expr=inner_expr

)

2.ALL/ANY/SOME子查询的优化

other_expr operator ANY (subquery)

// ALL：对于子查询所有行数据进行operator操作成功

other_expr operator SOME (subquery)

// ANY：对于子查询任意行数据进行operator操作成功

other_expr operator ALL (subquery)

// SOME：同ANY，mysql中用法是相同的

一些适用的转化规则。

转化前sql形式转化后sql形式= ANY (...)IN (...)!= ALL (...)NOT IN (...)!= ANY (...)NOT IN (...)val >= ALL (select ...)val >= MAX(select ...)val <= ALL (select ...)val <= MIN(select ...)val >= ANY (select ...)val >= MIN(select ...)val <= ANY (select ...)val <= MAX(select ...)

3.EXISTS子查询的优化

exists本身有着“半连接”的语义。

所以在一些数据库实现中（比如pg），使用半连接来完成exists。

一些in的子查询是可以等价转换成exists格式的。

而exists格式是可以转换成semi join格式的。

// 优化前的sql

exists(

select 1 from ...

where subquery_where and

outer_expr=inner_expr

)

// 优化后

select * from outer_table

semi join inner_table on outer_expr=inner_expr

where subquery_where

举几个例子来进行说明。

// 实例一：子查询条件和父查询有关联

select t1.* from t1 where exists ( select t2.id from t2 where t1.id=t2.id );

select t1.* from t1 semi join t2 on t1.id=t2.id;

// 实例二：子查询条件和子查询没有关系

select t1.* from t1 where exists ( select t2.id from t2 where t1.id=10 );

select t1.* from t1 semi join t2 on t1.id=10;//还能再优化，不过当前是优化到这一步

// 实例三：非关联子查询

select t1.* from t1 where exists ( select t2.id from t2 where t2.id=10 );

select t1.* from t1 where exists ( select t2.id from t2 where t2.id=10 );//非关联不进行优化

// 实例四：非关联子查询，且无表

select t1.* from t1 where exists ( select 10 );

select t1.* from t1 where exists ( select 10 ); //同实例三

mysql和pg的支持项

常见的可优化的子查询类型PostgreSQL支持优化MySQL支持优化IN类型支持可使用Hash连接、Hash半连接、嵌套循环半连接等算法进行优化支持相当与=ANY操作可使用Semi-join、Materialization、EXISTS strategy三种方式对IN进行优化 NOT IN类型不支持支持可使用Materialization、EXISTS strategy两种方式对IN进行优化 ALL类型不支持 >ALL:用MAX优化 =ALL:用EXISTS strategy方式优化 ANY:用MIN优化 =ANY:用EXISTS strategy方式优化 SOME:用MIN优化 =SOME:用EXISTS strategy方式优化

视图重写优化

视图是基于表的一种对象。视图重写就是将对视图的引用改写为对基本表的引用。

所有的视图都可以被子查询替换，但不是所有的子查询都可以被视图替换，关联子查询就不行。

// 视图重写的例子如下：

create table t1(a int, b int);

create view v_t1 as select * from t1;

// 查询视图的语句如下：

select a from v_t1 where b>100;

// 视图消除改写后：

select a from (

select a,b from t1

)

where b > 100;

// 优化后

select a from t1 where b > 100;

SPJ视图能够被查询优化器处理，但是比较复杂的视图处理起来就很麻烦了。

oracle提供了“复杂视图合并”，“物化视图查询重写”等方法，但是复杂视图查询技术本身还有待提高。

等价谓词重写

因为数据库执行引擎可能对某一类的谓词的处理效率更高，所以会对谓词进行等价的重写来达到更高的处理效率。

常见的等价谓词重写规则有：

谓词重写规则重写前重写后LIKE 规则 // case 1 name like 'ABC%' // case 2 name like 'ABC' // case 1 name >='ABC' and name<'ABD' // case 2 name ='ABC' BETWEEN-AND规则 // case 1 sno BETWEEN 10 AND 20 //case 1 sno>=10 AND ano<=20 IN转OR规则 // case 1 age in (8,12,13) //case 1 age =8 or age=12 or age=13 IN转ANY规则 // case 1 age in (8,12,13) // case 1 age = any (8,12,13) OR转ANY规则 // case1 age =5 or age=6 or age=7 // case 1 age = any(5,6,7) ALL/ANY转聚合参考ALL/ANY/SOME子查询优化规则参考ALL/ANY/SOME子查询优化规则NOT规则 // case 1 NOT(col_1!=2) // case 2 NOT(col_1!=col_2) // case 3 NOT(col_1=col_2) //case 4 NOT(col_1=col_2 OR转UNION规则 // case1 select * from t1 where id>10 or id<5 // case1 select * from t1 where id>10 union select * from t1 where id<5

表达式优化及条件化简

数据过滤条件一般存在于where子句，having子句，on子句。

这些条件子句一般由多个表达式组成，可以利用等式性质进行化简。

条件化简是分为两种的，一种是多个表达式之间的简化，另一种是表达式本身的简化。

单个表达式的简化

多个表达式之间的简化

条件化简方式化简前化简后 having/where条件合并（仅当having中没有聚合结果列） select * from t1 where id>5 having name='aiky';select * from t1 where id>5 and name='aiky'; 去除表达式中冗余的括号（多余括号会增加表达式树深度） ((a AND b) AND (c AND d))a AND b AND c AND d 常量传递（消除依赖，使用索引） col_1=col_2 AND col_2=3col_1=3 AND col_2=3不等式变换a>10 AND b=6 AND a>2a>10 AND b=6 谓词传递闭包（使用索引，提前过滤） a > b AND b > 2 a>b AND b>2 AND a>2消除死码0>1 OR a=5a=5合取项只要有一个为假，即整个表达式为假0>1 AND s1=5 falseAND操作符交换a>b AND b>2 AND a>2b>2 AND a>2 AND a>b

pg，mysql，ck支持项

条件简化规则Postgresqlmysqlclickhouse把HAVING子句并入WHERE子句支持支持支持去除表达式中冗余的括号支持支持不支持常量传递支持支持不支持消除死码支持支持不支持表达式计算支持不支持不支持等式变换不支持不支持不支持不等式变换不支持不支持不支持谓词传递闭包不支持不支持不支持合取项只要有一个为假，即整个表达式为假支持支持支持AND操作符交换支持支持支持

连接相关优化

1.外连接消除

外连接指left join，right join，full join。

查询重写可以在满足一定条件下将外连接转换为内联接。转换的意义如下：

外连接的执行操作和时间多于内连接使用内连接更加灵活多变使用内连接在一些连接算法下可以减少循环次数

外连接到内连接的转化

总结下来就是：当过滤条件中满足内表列的“空值拒绝”，就可以转为内联接。

// 1. 某个谓词的表达式用NULL值计算后会得到False或NULL。

select * from t1 left join t2 on t1.id = t2.id where t2.id is not null;

select * from t1 left join t2 on t1.id = t2.id where t2.value > 3;

// 2. 多个谓词用AND连接，其中一个能够过滤NULL。

select * from t1 left join t2 on t1.id = t2.id where t2.value > 3 and t2.id is null;

// 3. 多个谓词用OR连接，每一个都能够过滤NULL。

select * from t1 left join t2 on t1.id = t2.id where t2.id is not null or t2.value > 3;

外连接消除

优化原理：

如果去掉外连接，对最后的查询结果没有影响，那么就可以进行外连接消除。

对于外连接，外表的每一行记录肯定会在连接的结果集里出现一次或多次，如果内表在连接列上满足唯一性属性，外表的每一行记录仅会在连接结果中出现一次。如果join的上层算子只需要外表列的数据，那么join将会成为无用操作，这种情况下的外连接结果集等价于直接读取外表列的数据。

若内表在连接列上不满足唯一性属性，外表的行可能在内表找到多行匹配，则外表的一行会在连接结果中出现多次，当上层算子只需要 outer plan 的去重后结果时，外连接同样也可以被消除。

使用场景：

外连接查询中同时满足以下条件1、2或1、3可应用外连接消除优化规则：

1. join算子节点的父亲算子只会用join算子输出的外表列进行计算。

2. join算子的连接条件中的内表列满足唯一性属性。

3. join算子的父亲算子会对输入的记录去重。

保证join算子的父亲算子只会用到join中外表的去重后结果。

举例：

// case 1

select t1.a from t1 left join t2 on t1.b = t2.pk;

// case 1 优化

select a from t1;

// case 2

select distinct(t1.a) from t1 left join t2 on t1.b = t2.b;

// case 2 优化

select distinct(a) from t1;

2.嵌套连接优化

嵌套连接指，当执行连接操作的次序不是从左到右逐个进行，就说明存在嵌套连接。

嵌套链接情况举例：

// case 1, 使用外连接

select * from t1 left join (

t2 left join t3 on t2.id=t3.id

) on t1.a=t2.a

where t1.a>1

// case 2, 使用内连接

select * from t1 join (

t2 left join t3 on t2.id=t3.id

) on t1.a=t2.a

where t1.a>1

如果连接表达式中只有内连接，那么可以去掉括号，顺序可以颠倒。

如果是外连接，那么不能去掉括号，但是可能可以做向内连接的转换。

3.pg，mysql，ck 连接优化

连接类型连接语法格式 PostgreSQL MySQL ClickHouse 内连接[INNER | CROSS] JOIN满足连接交换律，可互换表位置，优化点在于多表连接时对表的连接次序的选择多表连接的次序由表的数量决定，即使是内连接，也不可互换表的位置不支持优化左外连接LEFT [OUTER] JOIN内表的条件列满足空值拒绝，可优化为内连接同PostgreSQL不支持优化右外连接RIGHT [OUTER] JOIN转为左外连接，再进行优化同PostgreSQL不支持优化全外连接FULL [OUTER] JOIN 外表的条件列满足空值拒绝，向左外连接转化内表的条件列满足空值拒绝，向右外连接转化（右外连接又转化为左外连接的形式）外表、内表的条件列都满足空值拒绝，向内连接转化不支持优化不支持优化半连接EXISTS支持优化（如用Hash Join优化）不支持优化不支持优化反半连接NOT EXISTS支持优化（如用Hash Anti Join优化）不支持优化不支持优化

列裁剪优化

主要影响的算子： Projection，Aggregation，DataSource

做列裁剪时，依据执行节点结构自底向上，看它父节点要哪些列，然后它自己的条件里面要用到哪些列。仅保留需要用到的列。

对于用不上的列，不需要读取对应的数据，减少IO资源的浪费。

// 假设表t有 a, b, c, d四列，查询：

select a from t where b < 5;

// 只用到了a, b两列的数据，读数据时只需要读取a, b两列即可。

算子下推

查询优化器的目的本质，就是尽可能提前的过滤掉数据，越早过滤数据，越能减少计算耗费的cpu，数据占用的内存量。

1.谓词下推

可以理解为将 where条件/having 条件/ on条件尽可能的放在执行器最前面的位置。

where谓词/having谓词下推场景

谓词条件inner joinleft join right joinfull joinleft tableright tableleft tableright tableleft tableright tableleft tableright tablewhere predicate√√√××√××

以left join的为例对不能下推的情况说明：

对于left join若找不到匹配的行，会对右表列进行补null，若对右表的条件谓词进行下推，那么右表过滤后再join可能会出现很多需要补null的行，这些行没有了过滤条件会被全部返回。但是下推的这个where条件没下推之前实际上是可以把null过滤掉的，这样就出现了优化前后结果集数据不一致的情况。其它join方式同理。

join on谓词下推场景

条件inner joinleft join right joinfull joinleft tableright tableleft tableright tableleft tableright tableleft tableright tablejoin predicate√√×√√×××

以left join的为例对不能下推的情况说明：

由于左表是保留表，因此结果集包含了左表的全部行，若将左表条件进行下推，则会提前过滤左表的表分数据，再进行join会造成下推前后结果集不一致。

2.TopN和Limit下推（分布式场景）

查询计划树中，limit子句对应Limit算子节点，order by子句对应sort算子节点，将相邻的limit和sort算子组合为TopN算子节点，表示按照某个排序规则提取前N项记录。

单独的limit算子等价于一个排序规则为空的TopN算子节点。

优化原理：

和谓词下推类似，将查询计划树中的TopN计算尽可能下推至数据源，尽早完成过滤数据，从而减少数据的传输和计算开销。

使用场景：

非join场景

查询只涉及单表，可直接将TopN算子下推至存储层对数据进行过滤。

join场景

当join方式为outer join，且排序规则仅依赖于外表中的列，可以将TopN算子下推至对应数据源。因为外连接会保留外表所有的行，每行数据至少出现一次，排序仅依赖外表的内容时，提前排序再join并不会改变结果集。

其它join场景无法进行TopN下推，因为其它join并不能保证排序列对应的表中的所有行都会被保留在join结果集中，若进行下推可能会造成结果集的缺失。

使用方式：

将TopN下推至存储层，先在存储层做局部sort，然后将所有的局部结果汇总，在计算层做合并进行二次sort。

当排序的列是对应表的主键时，可以直接按顺序读取数据，TopN算子将简化为Limit算子。

能够TopN下推的join场景：

select * from t1 left join t2 on t1.id = t2.id oder by t1.a limit 10;

max/min消除

优化原理：

将 max/min 聚合函数转换为 TopN 算子，从而能够有效地利用索引进行查询。

使用场景：

只有一个max或min函数，max/min的聚合函数参数中的列有索引能够保序，且没有group by 语句。存在多个max或min函数，每个max/min的聚合函数参数中的列都有索引能够保序，并且没有group by语句。

使用方式：

// 只有一个max/min函数

// 将查询进行等价改写，以TopN算子对max/min进行替换来避免全表扫描：

select min(id) from t;

select id from t order by id desc limit 1;

// 多个max/min函数

select max(a) - min(a) from t

select max_a - min_a from (

select a as max_a from t order by a asc limit 1

) t1, (

select a as min_a from t order by a desc limit 1

) t2;

// 如果a列没有可以保序的索引，则这个规则不会被应用。

3.聚合下推

单机情况下：

考虑多表join时，带有聚合函数的情况。

// 优化前

select LT.id, sum(LT.salary)

from left_table_agg LT join right_table_agg RT

on LT.id = RT.id

group by LT.id;

// 优化后

select LT.id, sum(LT.salary)

from (

select id as id , sum(salary) as salary from left_table_agg group by id

) LT join right_table_agg RT

on LT.id = RT.id

group LT.id;

分布式情况下：

提前过滤数据，减少网络传输。

聚合方式下推方式 max上层聚合：max 下推聚合：maxmin上层聚合：min 下推聚合：minsum上层聚合：sum 下推聚合：sumcount上层聚合：sum 下推聚合：count avg 上层聚合：sum/count 下推聚合：sum, count

RBO优化框架的问题

随着逻辑优化规则的不断增多，优化框架可能存在的几个问题：

优化器要求每个逻辑优化规则一定是有收益的，转换后得到的逻辑执行计划必须比转换前的更优（例如谓词下推），但是某些优化规则只在特定场景下有收益，由于需要考虑特定场景的某些条件，这种优化规则很难添加到逻辑执行优化的优化器中，导致优化器在那些特定场景下的执行计划不够优。不管什么样的 SQL，在逻辑优化阶段，所有的优化规则都按照同一个固定的顺序依次去看是否能够作用于当前的逻辑执行计划，例如最先执行的规则总是列剪裁。逻辑优化规则之间的顺序需要经过有经验的优化器老手精心的安排，在添加优化规则的时候都需要小心翼翼地安排这个顺序，添加一个优化规则需要了解其他所有优化规则，门槛较高。逻辑优化阶段，每个规则至多只会在被顺序遍历到的时候执行一次，但实际场景中，往往存在之前某个已经执行过的优化规则可以再次被执行的情况。我们以一个例子来说明，对于这个简单的 SQL：select b from t where a > 1，其中 a 是 int 类型的主键，我们最终会产生这样一个物理执行计划： TableScan(table: t, range:(1, inf]) -> TableReader(a, b) -> Projection(b)

在 TableReader 的 Schema 中包含了 a b 两列，也就是说会从T中读取两列内容，但最终自己却只需要其中第一列。这个问题背后的原因是：优化器先进行列裁剪，再谓词下推，但是谓词下推之后，有可能列剪裁可以再次生效，而这个可能生效的列剪裁在现在优化器中无法被执行了，导致从T多读取了一列数据，增加了 SQL 执行时的网络 IO 使用量。

主要就这些了，之后我再调研一下更普遍的查询优化器，写一下cbo的实现吧，从数据库厂商们的查询优化器走向来看，cbo更主流一点。

优惠劵

Aiky哇

关注

踩

觉得还不错?

一键收藏

打赏

知道了

数据库查询优化器，RBO优化规则介绍及示例

数据库查询优化器是针对于sql经过解析后生成的ast表达式树的。目的是能够降低sql执行计算量，简化计算。传统数据库中，查询优化是很复杂的，大体上可以分为RBO和CBO，其中CBO的收益性不确定，需要进行代价估算，依赖的数据统计会比较多。而RBO规则优化在不需要了解数据统计信息的前提下，可以明确提升sql执行计划的查询性能。现在的数据库厂商大多使用的是RBO+CBO或者只用CBO的架构。其实只用CBO更主流一些，TIDB,PolarX都在用，只用cbo搜索空间相对更完整，优化结果更接近全局最优。

复制链接

扫一扫

专栏目录

columbia:针对大型复杂联接查询的高效数据库查询优化器

05-29

哥伦比亚

针对大型复杂联接查询的高效数据库查询优化器

对于在线分析处理（OLAP）和大数据仓库的查询功能的新兴趣，给商业关系数据库中的当前优化器带来了新的挑战，而事实证明，这些优化器通常不足以满足这些应用程序领域的需求。查询优化器已经是数据库系统中最大，最复杂的模块之一，并且事实证明，它们很难进行修改和扩展以适应这些领域。

哥伦比亚查询优化器框架为决策支持查询的聚合转换提供了有效的测试环境。这是我在波特兰州立大学的硕士论文研究期间编写的哥伦比亚查询优化器的源代码。

哥伦比亚查询优化器项目页面： :

优化器的RBO和CBO

mj19967的博客

05-27

2325

优化器:分为RBO 和CBO 两种类型,RBO(Rule-Based Optimizer)基于规则的优化器,CBO(Cost-Based Optimizer)基于成本的优化器。目的是为了得到目标SQL的执行计划。

SQL语句的执行过程：

RBO：

Oracle会在代码里事先为各种类型的执行路径定一个等级，一共15个等级，从等级1到等级15，orac...

参与评论

您还未登录，请先

后发表或查看评论

Oracle中的优化器--CBO和RBO

小麦苗DBA宝典

06-13

659

Oracle中的优化器--CBO和RBO

Oracle数据库中的优化器又叫查询优化器（Query Optimizer）。它是SQL分析和执行的优化工具，...

ORACLE CBO RBO 优化器介绍与区别

最新文章

记在2023/8/24

docker之WORKDIR指令

解决Golang获取当前项目绝对路径问题

2023年15篇

2022年94篇

2021年47篇

2020年54篇

分类专栏

docker

1篇

35篇

调试工具

12篇

测试调研

11篇

postgresql

19篇

python

10篇

数据库架构

19篇

算法

17篇

k8s

10篇

不务正业

1篇

clickhouse

36篇

c++

13篇

读书笔记

14篇

git

1篇

linux

11篇

mysql

24篇

面试

6篇

sql查询优化

2篇

zookeeper

1篇

设计模式

12篇

网络协议

2篇

tidb

3篇

shell

3篇

分布式

5篇

raft协议

6篇

spark

1篇

citus

3篇

被折叠的条评论

为什么被折叠?

到【灌水乐园】发言

查看更多评论

添加红包

祝福语

请填写红包祝福语或标题

红包数量

个

红包个数最小为10个

红包总金额

元

红包金额最低5元

余额支付

当前余额3.43元

前往充值 >

需支付：10.00元

取消

确定

下一步

知道了

成就一亿技术人!

领取后你会自动成为博主和红包主的粉丝

规则

hope_wisdom 发出的红包

打赏作者

Aiky哇

你的鼓励将是我创作的最大动力

¥1

¥2

¥4

¥6

¥10

¥20

扫码支付：¥1

获取中

扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元

使用余额支付

点击重新获取

扫码支付

钱包余额

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值

半导体封装胶粘剂简介（18）-树脂溢出现象RBO - 知乎

半导体封装胶粘剂简介（18）-树脂溢出现象RBO - 知乎首发于半导体导电胶切换模式写文章登录/注册半导体封装胶粘剂简介（18）-树脂溢出现象RBOColinWu2020上海本诺电子材料有限公司运营总监历史回顾: 之前的文章简单的介绍过，终端客户在电子胶粘剂的使用中通常会遇到的问题: 【免费】半导体封装胶粘剂简介(8)-常见问题今天这篇文章主要是归纳总结一下芯片封装过程中时常会遇到的树脂溢出问题[RBO(Resin Bleeding Out)，或称ERO (Epoxy bleed out)]。随着微电子继续向更小的外形、更高的可靠性和更好的性能发展，RBO的控制对在芯片封装尤其是在多芯片封装变得越来越重要。1.RBO简介将胶粘剂点到基板或粘接界后，树脂从胶粘剂中迁移出来，在芯片周围扩散，形成澄清无色或者琥珀色的有机污染状的环状阴影，如下图. 当树脂严重扩散时会严重影响后续的打线（wire bonding)，密封（Sealing/molding) 等工艺.原理当胶粘剂点到基板框架上，胶水通常会部分湿润基板表面。胶水与基板之间的粘合力导致粘贴扩散，而胶粘剂自身的聚力将保持成分在一起，避免与框架表面接触。粘合力和凝聚力是相互交际的力量，如氢粘结力和范德瓦尔斯力。因此，湿润程度将取决于粘合力和凝聚力之间的平衡。当配方中的一些成分原料对基材的粘合力强于粘贴内的凝聚力时，就会RBO。 RBO的驱动力是通过湿润来最大限度地减少基材的表面能量。目前芯片尺寸越来越小，对RBO容忍度也越来约低, 值得注意的是，需要合理区分是RBO还是加热气流的影响，如图1.2.造成RBO原因导致树脂溢出RBO的原因有很多，包括液体浸润的的热力学原理（表面张力），胶粘剂/基板的性能，以及胶粘剂固化流程等2.1 基材的表面能/张力差异影响通常，粘接的基材表面要比胶粘剂的表面能要高，这样才能够很好的润湿基材，达到理想的粘接效果。即使是同一款胶水，在不同表面能的基材上的RBO表现不尽相同，尤其是在Au金的界面上，会更加明显. 客户端的工艺不同，选择的粘接界面也会多种多样，时常发生彼之蜜糖，我之砒霜（附上一些基板和树脂的表面张力数据）2.2 胶粘剂的表面张力影响胶粘剂通常是由2种或多种树脂混合均匀组成，如果其中一种或几种树脂对基材表面的亲和力大于其自身凝聚力（表面张力），树脂从自身溢出，RBO就会发生。一般来说，低粘度的胶粘剂会比高粘度的胶粘剂更容易发生RBO，主要是受毛细现象和胶粘剂本身的浸润动力影响，同时，密度差异，树脂高分子的分子量分布，填料的种类等因素也会影响RBO现象。补充：表面张力受温度影响，所以当看到表面张力的数值时必须标明所对应的温度，一般情况下，表面张力随着温度的升高而降低，直到某一临界温度时达到0，所以为什么有些黏合剂，在高温固化的粘接强度比常温固化要好，也跟表面张力更低润湿性更好有关吧。2.3 胶水固化工艺影响胶水点胶后，控制好放置的时间（Stag)，放置时间太长时间，同时固化时间太长，RBO的问题会变得更严重减少点胶后的放置时间，尽量提高固化温度，都会有效降低RBO（但目前随着封装工艺发展，对低温快速固化胶水的需求越来越高） 2.4. 基材表面粗糙和清洁度 a.基材表面太粗糙，会加剧RBO问题粗糙度比是AFM计算的实际三维表面积与平面面积之间的比率。研究发现粗糙度比与RBO之间有良好的相关性:随着表面粗糙度比的增加，RBO越来越严重b.基板的清洁度在基板制造过程中，会在表面电镀上一层金或银等金属；电镀槽中的有机物，无机物可能会嵌附于基材内部表面，影响后续的胶粘剂的RBO现象。同样，电镀过程造成表面形貌差异也会影响RBO.3.RBO改善措施3.1 基材品质管控处理 RBO现象不仅仅胶粘剂的问题，主要是胶粘剂在不同基材的表现。因而，对于基材品质管控尤为重要，每个来料批次务必进行RBO的IQA测试。对于基材也快以进行以下2个方式，改善基材表面性能： 1）真空烘烤： 200C真空烘烤2-4小时可以有效去除基材表面污染物，改善RBO现象。 2）Plasma清洁：目前最常用的处理方式，可以去除表面的污染物等，同时也会提高粘接力（比如PTFE等塑料）值得注意的是，Plasma是用以清洁去除污染物，但会增加基材表面能，RBO问题可能会因表面能量的增加而变得更加明显。3.2 改善胶水配方 RBO成分可以是溶剂、活性稀释剂、低分子量树脂、催化剂和粘附促进剂等。一般来说，Anti-bleeding组分被添加到胶粘剂中以减少或消除RBO。不同的ANTIBLEED剂可能有不同的工作机制:一些增强糊状物的凝聚力，而另一些则添加到形成薄层，其表面能量低于铅框架表面。因此，用适当的antibleeding组分对于防止不同类型的铅框架上的 RBO 至关重要，同时保持金属铅框架的高粘附性以实现高可靠性。3.3 使用胶膜替代消除RBO 的最简单和最有效的方法是胶膜。但是，此方法存在一些限制因素，括高材料成本和资本投资，难以实现高粘附性，从而高可靠性，以及这些材料的热性能有限。3.4 设计中增加机械障碍，控制RBO 在某些情况下，在打线和芯片之间设计凹槽或围墙，以减少RBO蔓延区域，如下图黄色所示。这是一个简单且具有成本效益的做法。但是，如果RBO严重，这种方法可能效果不好。同样，可以在芯片周围打印一些低表面能量绝缘膜，限制RBO问题。4.讨论Q&A 实际生产过程中，你遇到过什么情况的RBO问题，最后又是怎么解决的？评论区期待您的分享交流！同时建了一个半导体互动群，期待您的加入.可以加我微信WX: 139 1771 2829 拉你进群。上海本诺电子材料有限公司位置：上海市闵行区颛桥镇瓶安路1298号发布于 2021-09-06 08:54半导体微电子电子封装技术赞同 91 条评论分享喜欢收藏申请转载文章被以下专栏收录半导体导电胶半导体

ORACLE优化器RBO与CBO介绍总结 - 潇湘隐者 - 博客园

会员

周边

新闻

博问

AI培训

云市场

所有博客

当前博客

我的博客

我的园子

账号设置

简洁模式 ...

退出登录

代码改变世界

Cnblogs

Dashboard

Home

Contact

Gallery

RSS

潇湘隐者

ORACLE优化器RBO与CBO介绍总结

2014-07-14 10:38

潇湘隐者

阅读(55955)

编辑

RBO和CBO的基本概念 Oracle数据库中的优化器又叫查询优化器（Query Optimizer）。它是SQL分析和执行的优化工具，它负责生成、制定SQL的执行计划。Oracle的优化器有两种，基于规则的优化器（RBO）与基于代价的优化器（CBO) RBO: Rule-Based Optimization 基于规则的优化器 CBO: Cost-Based Optimization 基于代价的优化器 RBO自ORACLE 6以来被采用，一直沿用至ORACLE 9i. ORACLE 10g开始，ORACLE已经彻底丢弃了RBO，它有着一套严格的使用规则，只要你按照它去写SQL语句，无论数据表中的内容怎样，也不会影响到你的“执行计划”，也就是说RBO对数据不“敏感”；它根据ORACLE指定的优先顺序规则，对指定的表进行执行计划的选择。比如在规则中，索引的优先级大于全表扫描;RBO是根据可用的访问路径以及访问路径等级来选择执行计划，在RBO中，SQL的写法往往会影响执行计划，它要求开发人员非常了解RBO的各项细则，菜鸟写出来的SQL脚本性能可能非常差。随着RBO的被遗弃，渐渐不为人所知。也许只有老一辈的DBA对其了解得比较深入。关于RBO的访问路径，官方文档做了详细介绍： RBO Path 1: Single Row by Rowid RBO Path 2: Single Row by Cluster Join RBO Path 3: Single Row by Hash Cluster Key with Unique or Primary Key RBO Path 4: Single Row by Unique or Primary Key RBO Path 5: Clustered Join RBO Path 6: Hash Cluster Key RBO Path 7: Indexed Cluster Key RBO Path 8: Composite Index RBO Path 9: Single-Column Indexes RBO Path 10: Bounded Range Search on Indexed Columns RBO Path 11: Unbounded Range Search on Indexed Columns RBO Path 12: Sort Merge Join RBO Path 13: MAX or MIN of Indexed Column RBO Path 14: ORDER BY on Indexed Column RBO Path 15: Full Table Scan CBO是一种比RBO更加合理、可靠的优化器，它是从ORACLE 8中开始引入，但到ORACLE 9i 中才逐渐成熟，在ORACLE 10g中完全取代RBO， CBO是计算各种可能“执行计划”的“代价”，即COST，从中选用COST最低的执行方案，作为实际运行方案。它依赖数据库对象的统计信息，统计信息的准确与否会影响CBO做出最优的选择。如果对一次执行SQL时发现涉及对象（表、索引等）没有被分析、统计过，那么ORACLE会采用一种叫做动态采样的技术，动态的收集表和索引上的一些数据信息。关于RBO与CBO，我有个形象的比喻：大数据时代到来以前，做生意或许凭借多年累计下来的经验（RBO）就能够很好的做出决策，跟随市场变化。但是大数据时代，如果做生意还是靠以前凭经验做决策，而不是靠大数据、数据分析、数据挖掘做决策，那么就有可能做出错误的决策。这也就是越来越多的公司对BI、数据挖掘越来越重视的缘故，像电商、游戏、电信等行业都已经大规模的应用，以前在一家游戏公司数据库部门做BI分析，挖掘潜在消费用户简直无所不及。至今映像颇深。 CBO与RBO的优劣 CBO优于RBO是因为RBO是一种呆板、过时的优化器，它只认规则，对数据不敏感。毕竟规则是死的，数据是变化的，这样生成的执行计划往往是不可靠的，不是最优的，CBO由于RBO可以从很多方面体现。下面请看一个例子，此案例来自于《让Oracle跑得更快》。 SQL> create table test as select 1 id ,object_name from dba_objects; Table created. SQL> create index idx_test on test(id); Index created. SQL> update test set id=100 where rownum =1; 1 row updated. SQL> select id, count(1) from test group by id; ID COUNT(1)---------- ---------- 100 1 1 50314

从上面可以看出，该测试表的数据分布极其不均衡,ID=100的记录只有一条，而ID=1的记录有50314条。我们先看看RBO下两条SQL的执行计划.

SQL> select /*+ rule */ * from test where id =100; Execution Plan----------------------------------------------------------Plan hash value: 2473784974 ------------------------------------------------| Id | Operation | Name |------------------------------------------------| 0 | SELECT STATEMENT | || 1 | TABLE ACCESS BY INDEX ROWID| TEST ||* 2 | INDEX RANGE SCAN | IDX_TEST |------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 2 - access("ID"=100) Note----- - rule based optimizer used (consider using cbo) Statistics---------------------------------------------------------- 1 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 588 bytes sent via SQL*Net to client 469 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL>

SQL> select /*+ rule */ * from test where id=1; 50314 rows selected. Execution Plan----------------------------------------------------------Plan hash value: 2473784974 ------------------------------------------------| Id | Operation | Name |------------------------------------------------| 0 | SELECT STATEMENT | || 1 | TABLE ACCESS BY INDEX ROWID| TEST ||* 2 | INDEX RANGE SCAN | IDX_TEST |------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 2 - access("ID"=1) Note----- - rule based optimizer used (consider using cbo) Statistics---------------------------------------------------------- 1 recursive calls 0 db block gets 7012 consistent gets 97 physical reads 0 redo size 2243353 bytes sent via SQL*Net to client 37363 bytes received via SQL*Net from client 3356 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 50314 rows processed

从执行计划可以看出，RBO的执行计划让人有点失望，对于ID=1，几乎所有的数据全部符合谓词条件，走索引只能增加额外的开销（因为ORACLE首先要访问索引数据块，在索引上找到了对应的键值，然后按照键值上的ROWID再去访问表中相应数据），既然我们几乎要访问所有表中的数据，那么全表扫描自然是最优的选择。而RBO选择了错误的执行计划。可以对比一下CBO下SQL的执行计划，显然它对数据敏感，执行计划及时的根据数据量做了调整,当查询条件为1时，它走全表扫描；当查询条件为100时，它走区间索引扫描。如下所示：

SQL> select * from test where id=1; 50314 rows selected. Execution Plan----------------------------------------------------------Plan hash value: 1357081020 --------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |--------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 49075 | 3786K| 52 (2)| 00:00:01 ||* 1 | TABLE ACCESS FULL| TEST | 49075 | 3786K| 52 (2)| 00:00:01 |--------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 1 - filter("ID"=1) Note----- - dynamic sampling used for this statement Statistics---------------------------------------------------------- 32 recursive calls 0 db block gets 3644 consistent gets 0 physical reads 0 redo size 1689175 bytes sent via SQL*Net to client 37363 bytes received via SQL*Net from client 3356 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 50314 rows processed SQL> select * from test where id =100; Execution Plan----------------------------------------------------------Plan hash value: 2473784974 ----------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |----------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 79 | 2 (0)| 00:00:01 || 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 79 | 2 (0)| 00:00:01 ||* 2 | INDEX RANGE SCAN | IDX_TEST | 1 | | 1 (0)| 00:00:01 |----------------------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 2 - access("ID"=100) Note----- - dynamic sampling used for this statement Statistics---------------------------------------------------------- 9 recursive calls 0 db block gets 73 consistent gets 0 physical reads 0 redo size 588 bytes sent via SQL*Net to client 469 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL>

仅此一项就可以看出为什么ORACLE极力推荐使用CBO，从ORACLE 10g开始不支持RBO的缘故。所谓长江后浪推前浪，前浪死在沙滩上。

CBO知识点的总结

CBO优化器根据SQL语句生成一组可能被使用的执行计划，估算出每个执行计划的代价，并调用计划生成器（Plan Generator）生成执行计划，比较执行计划的代价，最终选择选择一个代价最小的执行计划。查询优化器由查询转换器（Query Transform）、代价估算器（Estimator）和计划生成器（Plan Generator）组成。

CBO优化器组件

CBO由以下组件构成：

· 查询转化器（Query Transformer）

查询转换器的作用就是等价改变查询语句的形式，以便产生更好的执行计划。它决定是否重写用户的查询（包括视图合并、谓词推进、非嵌套子查询/子查询反嵌套、物化视图重写），以生成更好的查询计划。

The input to the query transformer is a parsed query, which is represented by a set ofquery blocks. The query blocks are nested or interrelated to each other. The form of thequery determines how the query blocks are interrelated to each other. The mainobjective of the query transformer is to determine if it is advantageous to change theform of the query so that it enables generation of a better query plan. Several differentquery transformation techniques are employed by the query transformer, including:■ View Merging■ Predicate Pushing■ Subquery Unnesting■ Query Rewrite with Materialized ViewsAny combination of these transformations can be applied to a given query.

· 代价评估器（Estimator）

评估器通过复杂的算法结合来统计信息的三个值来评估各个执行计划的总体成本：选择性（Selectivity）、基数（Cardinality）、成本（Cost）

计划生成器会考虑可能的访问路径（Access Path）、关联方法和关联顺序，生成不同的执行计划，让查询优化器从这些计划中选择出执行代价最小的一个计划。

· 计划生成器（Plan Generator）

计划生成器就是生成大量的执行计划，然后选择其总体代价或总体成本最低的一个执行计划。

由于不同的访问路径、连接方式和连接顺序可以组合，虽然以不同的方式访问和处理数据，但是可以产生同样的结果

下图是我自己为了加深理解，用工具画的图

查看ORACLE优化器

SQL> show parameter optimizer_mode; NAME TYPE VALUE--------------------------- ----------- -----------------optimizer_mode string ALL_ROWS

修改ORACLE优化器

ORACLE 10g 优化器可以从系统级别、会话级别、语句级别三种方式修改优化器模式，非常方便灵活。

其中optimizer_mode可以选择的值有： first_rows_n,all_rows. 其中first_rows_n又有first_rows_1000, first_rows_100, first_rows_10, first_rows_1

在Oracle 9i中，优化器模式可以选择first_rows_n,all_rows, choose, rule 等模式：

Rule：基于规则的方式。

Choolse：指的是当一个表或或索引有统计信息，则走CBO的方式，如果表或索引没统计信息，表又不是特别的小，而且相应的列有索引时，那么就走索引，走RBO的方式。

If OPTIMIZER_MODE=CHOOSE, if statistics do not exist, and if you do not add hints to SQL statements, then SQL statements use the RBO. You can use the RBO to access both relational data and object types. If OPTIMIZER_MODE=FIRST_ROWS, FIRST_ROWS_n, or ALL_ROWS and no statistics exist, then the CBO uses default statistics. Migrate existing applications to use the cost-based approach.

First Rows：它与Choose方式是类似的，所不同的是当一个表有统计信息时，它将是以最快的方式返回查询的最先的几行，从总体上减少了响应时间。

All Rows: 10g中的默认值，也就是我们所说的Cost的方式，当一个表有统计信息时，它将以最快的方式返回表的所有的行，从总体上提高查询的吞吐

虽然Oracle 10g中不再支持RBO，Oracle 10g官方文档关于optimizer_mode参数的只有first_rows和all_rows.但是依然可以设置 optimizer_mode为rule或choose，估计是ORACLE为了过渡或向下兼容考虑。如下所示。

系统级别

SQL> alter system set optimizer_mode=rule scope=both; System altered. SQL> show parameter optimizer_mode NAME TYPE VALUE-------------------------------- ----------- -----------------------optimizer_mode string RULE

会话级别

会话级别修改优化器模式，只对当前会话有效，其它会话依然使用系统优化器模式。

SQL> alter session set optimizer_mode=first_rows_100;

Session altered.

语句级别

语句级别通过使用提示hints来实现。

SQL> select /*+ rule */ * from dba_objects where rownum <= 10;

扫描上面二维码关注我

如果你真心觉得文章写得不错，而且对你有所帮助，那就不妨帮忙“推荐"一下，您的“推荐”和”打赏“将是我最大的写作动力！

本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接.

会员力量，点亮园子希望

刷新页面返回顶部

About

www.spiga.com.mx

博客园

数据库内核-CBO 优化器基本概念 - 知乎

数据库内核-CBO 优化器基本概念 - 知乎首发于数据库内核与优化器切换模式写文章登录/注册数据库内核-CBO 优化器基本概念风杨守正出奇探讨计划数据库内核-优化器概述数据库内核-RBO 优化器数据库内核-CBO 优化器基本概念数据库内核-CBO 优化器采样与代价模型数据库内核-CBO 优化器执行计划数据库内核-子查询数据库内核-对Join 的优化数据库内核-Join Reorder 算法数据库内核-Join Reorder 优化数据库内核-HyperGraph数据库内核-Runtime Filter 论文导读数据库内核-动态过滤实现CBO 优化器基本概念以理论为主，如有错误请指正CBO 概念一条 SQL 查询到达数据库内核之后，会解析为一条逻辑执行计划，CBO 优化器对逻辑计划进行改写和转换，生成多个物理执行计划。为SQL构造出搜索空间，根据数据的统计信息、基数估计、算子代价模型为搜索空间中的执行机计划估算出执行所需要的代价（CPU、内存、网络、I/O 等资源消耗），最终选出代价最小的执行计划作为SQL的具体执行方式。CBO 优化器一般多采用 Volcano/Cascades 框架，两者优化思想基本相同，不同点在于Volcano 是先Explore后Build，而Cascades 是边Explore边Build，从而进一步裁剪掉一些执行计划。两者都基于多种统计信息进行代价估算，能够在数万级别的执行计划中，选择代价最低的执行计划，提升复杂查询的效率和性能。因此也称为查询计划枚举阶段。也因此统计信息成为了 CBO 优化器中的重要组成部分，统计信息的准确与否决定了代价估算是否准确，进而决定了CBO 优化器的性能好坏。CBO优化器同时更是针对JOIN的重要且实用的优化器，由于很多SQL业务场景都会涉及JOIN关联操作，所以采用CBO优化对于处理海量数据以及面临数量庞大且复杂的业务时，能够有效且大幅节省时间开销和资源开销。与RBO（Rule Based Optimization）的优化器相比，CBO优化框架通过Join Reordering、Bush Join Tree Generation等优化手段，对经过特殊转换后的执行计划进行了等价关系代数变换，对可能的等价执行计划，估算出量化的计划代价，最终选择出代价最小的作为最终的执行计划。最后需要注意的是,CBO的目的不是得到最优的方案,而是一个足够好的方案。执行框架一览常规CBO框架的核心组件模型包括：统计信息（Statistics）基数估算（Cardinality Estimation）转化规则（Transform Rules）代价模型（Cost Model）计划空间搜索引擎（Plan Space Search Engine）执行过程CBO的优化过程主要包含三步：Exploration、Build Physical Plan和Find Best Plan。Exploration 根据转换规则进行等价转换，生成多个逻辑执行计划Build Physical Plan 同RBO一样，决定各个Operator的具体实现Find Best Plan 根据统计信息计算各个执行计划的Cost，选出Cost最小的执行计划。总的来说就是利用转换规则搜索执行计划搜索空间，并评估每个执行计划代价找到最优解的过程。搜索引擎利用转换规则，对输入的逻辑执行计划进行(逻辑/物理)转换，构造出执行计划的搜索空间。之后，利用代价模型对搜索空间中的每一个执行计划进行代价估算，选出代价最低的物理执行计划。而代价估算的过程离不开基数估计：它利用各个表、列的统计信息，估算出各算子的输入行数、选择率等信息，提供给算子的代价模型，从而估算出查询计划的代价。CBO优化的关键步骤CBO的优化是基于代价、基于成本的优化器(Cost Based Optimizer)。那接下来聊些都有哪些关键步骤组成。1. 统计信息采集 Statistics表的统计信息采集是CBO最基础的一项工作，采集的主要信息以逻辑表为单位，包括表级别指标和列级别指标。包含：逻辑表的总行数，一般可以定义为 rowCount基本列信息 basicStats，包括列类型、Max(列的最大值)、Min(列的最小值)、number of nulls, number of distinct values(列NDV值), max column length, average column length等直方图信息 Histograms，用于区间查询，包括 Histograms of columns, i.e., Equi-height Histogram (等深直方图，for numeric and string types) and equi-width histogram (等宽直方图，only for numeric types)关于直方图1. 直方图常用于估算数据分布，当数据存在倾斜时，直方图可以弥补基础统计信息估算存在的偏差，输出更准确的数据分布信息。2. 直方图适用于有明显数据倾斜，并且有频繁查询请求的列。如果表数据分布比较均匀，可以不使用直方图。直方图适用的列类型一般可以为数值类型、DATE、DATETIME 或字符串类型。3. Equi-height Histogram: 即选定若干个 bucket，每个 bucket 中的数据量几乎相等。4. 对于出现频次较高、对选择率（selectivity）影响较大的数值，建议分配单独的桶进行存储。桶数量越多时，直方图的估算精度就越高，但是也会增加统计信息的内存使用。2. 基数估算 Cardinality Estimation基数估计（Cardinality Estimation）会估算各个算子中间结果的行数或基数等信息，例如Join输出行数，Agg会产生的Group数量等等。包括：Join结果的行数估算 : LeftRowCount * RightRowCount / MAX(LeftCardinality, RightCardinality)Union结果的行数估算: LeftRowCount + RightRowCountAgg结果的行数估算: Group By列的Distinct值数量（NDV）Filter结果的行数估算: 对于等值条件，使用NDV估算选择率；对于范围查询，使用直方图估算选择率所以，为什么要采集这些信息？答案其实已经很明显了。算子的代价计算会依赖输入算子的数据量(行数)估算，行数的估算主要通过基数估计（Cardinality Estimation）和Statistics来完成，这两个指标是算子代价评估的直观体现，这两个值越大，给定算子执行代价必然越大，所以这两个值后续会用来评估实际算子的执行代价。对于LogicalVIew/TableScan，我们通过统计信息记录的RowCount就可以估算得比较准。而对于Filter这类过滤条件的估算需要依赖直方图，NDV(Number of Distinct Value)等信息估算Selectivity，再计算算子的RowCount。在实际SQL查询时对于大数据量的表我们不可能临时进行全表扫描统计相关的信息，支持CBO的数据库系统一般都实现了相关信息统计的方法。当用户发起ANALYZE TABLE命令，或者是后台auto analyze线程自动发起统计信息收集的时候，数据库一般都将会通过对逻辑表进行采样的方式收集数据并计算统计信息。比如很多数据库都会在各自的 meta文件中储相关的统计信息，ORC列式存储格式也存储了该文件相关的统计信息，或者通过 Hive/Presto/StoneDB/Doris/StarRocks 等数据库支持的Analyze命令、Impala的Compute命令可以获取。3. 算子的转化规则转化规则一般是指 Transform Rules。主要作用就是研究各种查询之间的关系，并从语法上甚至语义上给予SQL等价重写。对于实现规则，此处不展开。4. 执行计划的逻辑和物理转换一条规则由match pattern和转换逻辑组成，搜索引擎会根据规则的match pattern在执行计划中匹配其需要的关系代数节点（可以泛指Node）。按照规则的转换逻辑生成等价的执行计划。例如：我们希望考虑每一种Join顺序的执行计划对于的代价，就需要枚举出所有对应的执行计划。 Join Reorder是通过Join的交换律、结合律等规则来实现的。关系代数算子类型一条SQL查询在数据库系统中通常被Parse成抽象语法树(AST)，再转为一棵关系代数运算符组成的树，我们说的执行计划指的就是关系代数树。执行计划的组成常见关系代数算子有：Project：用于描述SQL中的SELECT列，包括函数计算Filter：用于描述SQL中的WHERE条件Join：用于描述SQL中的JOIN，其对应的物理算子有 HashJoin, BKAJoin, Nested-Loop Join, SortMergeJoin, Index NLJoin, Partitoin Wise Join等Agg：用于描述SQL中的Group By及聚合函数，其对应的物理算子有 HashAgg, Sort Agg等Sort：用于描述SQL中的Order By及Limit，其对应的物理算子有TopN、MemSortTableScan... ...关系型数据库中的查询，通常由关系代数算子组成的树状计划来表达5. 执行计划的代价模型评估一个执行计划的代价需要依赖统计信息，基数估算，代价模型。代价模型（Cost Model）是用于估算物理执行计划的代价，各个厂家的数据库内核中的代价模型会有略微差异，基本都可以用（CPU时间、Memory、IO、Net）四元组来描述。每一算子都会通过上述四元组来描述其代价，这个执行计划的代价即是其全部算子的代价的求和。最终优化器会根据求和后的CPU、Memory、IO、Net加权计算出执行计划最终的代价。CPU：代表CPU的消耗数值

Memory：代表Memory的占用量

IO：代表磁盘的逻辑IO次数

Net：代表网络的逻辑IO次数(交互次数及传输量)

最终Cost = (CPU, Memory, IO, Net) · (w1, w2, w3, w4)，W为权重向量在Prosto中，代价模型是 CPU时间、Memory、IO。在PolarDB-X中，代价模型是 CPU时间、Memory、IO、Net。6. 计划空间搜索引擎有了转换规则和代价模型，我们可以将执行计划进行逻辑与物理转换。但具体规则是怎么应用的、按照什么顺序去应用、怎么做得高效这是计划空间搜索引擎的重要职能。一般来讲，CBO优化器会选择 Volcano/Cascades 模型的优化方法，使用Top-Down的动态规划算法进行计划搜索。相比于传统以System R为代表的Bottom Up优化模型, Volcano/Cascades模型具有良好的扩展性可以较为优雅地支持像计算下推，以及Agg,Sort,Join相互Transpose的需求，具备搜索空间剪枝和物理属性驱动搜索的特性。此处涉及到更多的技术概念（本文以概念为主，后续再展开）：Top-Down动态规划Memo空间搜索Rule Apply OrderBranch And Bound空间剪枝Bottom-Up优化Interesting OrderDuplicate Free Join Reorder（用于解决重复计划生成的效率问题）StartUp Cost代价模型（用于解决存在不满足最优子结构性质算子的问题）Join Reorder（Bushy Tree、Zig-Zag Tree、Left Deep Tree、Heuristic）generate duplicate7. 选择最优的执行路径写了3天，突然发现文章内容太长了。这里收下尾。就不展开了。CBO的目的其实不是要得到一个绝对最优的方案, 而是在该SQL场景下相对足够好的方案。选择依据也很明朗：使用统计信息、查询转换等计算各种可能的成本代价，生成多种等价候选计划，最终选择成本最低的作为最优执行计划。编辑于 2023-12-01 11:05・IP 属地浙江优化策略优化器数据库内核赞同 11添加评论分享喜欢收藏申请转载文章被以下专栏收录数据库内核与优化器在这里一起学习和掌握数据

RGBD相机参数输出定义_d2c深度-CSDN博客

RGBD相机参数输出定义

奥比中光3D视觉开发者社区

于 2021-12-13 15:20:26 发布

阅读量642

点赞数

分类专栏：

结构光

开发者

3D视觉

文章标签：

自动驾驶

计算机视觉

原文链接：https://developer.orbbec.com.cn/forum_plate_module_details.html?id=1315

版权

开发者

同时被 3 个专栏收录

146 篇文章

21 订阅

订阅专栏

3D视觉

144 篇文章

63 订阅

订阅专栏

结构光

60 篇文章

9 订阅

订阅专栏

关于Orbbec Sensor SDK输出给用户的相机参数作如下规定：深度相机参数（内参、畸变等）与深度流需要一一对应：例如用户使用开启D2C的深度流，那就需要使用对应模式下相机参数转点云，因此使用的内参应该是RGB坐标系下的内参，不再是标定的深度相机的内参了。但是历史SDK输出给用户的depth相机参数均为标定时depth相机参数一组（不管是否进行了D2C），这样会导致用户将D2C后的深度转点云时出错，为避免次情况发生。Orbbec Sensor SDK定义D2C后深度流的内参定义为RGBD相机参数，区别于depth(未进行D2C)相机内参。 Orbbec Sensor SDK关于相机参数的处理方式如下（结构光项目可以通用）：备注：点击下面链接，进入奥比中光开发者社区，了解更多3D视觉技术信息：https://developer.orbbec.com.cn/

或扫描下方二维码,进入奥比中光开发者社区：

优惠劵

奥比中光3D视觉开发者社区

关注

踩

觉得还不错?

一键收藏

知道了

RGBD相机参数输出定义

复制链接

扫一扫

专栏目录

参与评论

您还未登录，请先

后发表或查看评论

博客

相约脑暴会，共创大未来——动态实时三维人体重建脑暴会

07-31

417

今夏我们召集江湖中的有识之士，共同探讨动态实时三维人体重建制作容积视频的方案，展开一场别开生面的脑暴会。在此，我们向全球开发者发出诚挚邀请，邀请您加入我们通过腾讯会议进行的的脑暴会，对于实现与改善动态实时三维人体重建项目进行进一步的讨论。

博客

【超详细】手把手教你使用YOLOX进行物体检测（附数据集）

03-29

4370

改进后的YOLO算法——YOLOX，不仅实现了超越 YOLOv3、YOLOv4 和 YOLOv5 的 AP，而且取得了极具竞争力的推理速度。本篇将超详细地讲解如何使用YOLOX进行物体检测，非常值得一读！

博客

大火的何恺明：MAE——用于计算机视觉的可扩展自监督学习神器

03-18

6129

作者：王浩毕业于北京航空航天大学，人工智能领域优质创作者，CSDN博客认证专家首发：公众号【3D视觉开发者社区】导语：近期，何铠明的新作可谓是火出了圈，毕竟何佬出品必是精品，由何佬提出的的ResNet、Faster RCNN等模型一直被大家学习和研究。如今，何铠明又带来一种用于计算机视觉的可扩展自监督学习器, 称之为”掩码自编码器 (MAE) “，本文将对该视觉学习器原理及实现方法进行解读。Masked Autoencoders Are Scalable Vision Learners论文.

博客

Q-YOLO：用于实时目标检测的高效推理

09-01

322

实时物体检测在各种计算机视觉应用中起着至关重要的作用

博客

一种在终端设备上用量化和张量压缩的紧凑而精确的视频理解

08-31

150

目前的工作集中在以分离的方式优化视频检测和分类。在今天分享中，我们介绍了一个用于终端设备的视频理解（目标检测和动作识别）系统，即DEEPEYE。

博客

Yolo框架大改 | 消耗极低的目标检测新框架

08-30

222

在过去的十年中，深度神经网络(DNNs)在各种应用中表现出显著的性能。

博客

Yolov5移植树莓派实现目标检测

08-29

229

项目主要是Yolov5进行目标检测，之后用树莓派作为上位机，将模型移植树莓派进行识别，控制下位机的运转。

博客

大白话用Transformer做BEV 3D目标检测

08-28

357

如何利用车载环视相机采集到的多张图像实现精准的 3D 目标检测，是自动驾驶感知领域的重要课题之一。

博客

自动驾驶视觉感知算法

08-25

167

本节我们先从广泛应用于自动驾驶的几个任务出发介绍2D视觉感知算法，包括基于图像或视频的2D目标检测和跟踪，以及2D场景的语义分割。

博客

视觉SLAM开源方案汇总及设备选型建议

08-24

266

SLAM 是 Simultaneous Localization and Mapping 的缩写，中文译作“同时定位与地图构建”

博客

目标检测的后处理：NMS vs WBF

08-23

160

模型集成是组合多个模型的预测以提高系统整体性能的过程

博客

最新综述！五大方向逐一梳理半监督目标检测进展

08-22

461

监督学习领域的目标检测算法已经比较成熟了，但是标签成本过高，存在一定的局限性

博客

超越GIoU/DIoU/CIoU/EIoU | MPDIoU让YOLOv7/YOLACT双双涨点，速度不减！

08-21

259

文章提出了一种基于最小点距离的边界框相似度比较度量——MPDIoU，其中包含了现有损失函数中考虑的所有相关因素，例如重叠或非重叠面积、中心点距离以及宽度和高度的偏差，同时简化了计算过程。边界框回归（Bounding Box Regression，BBR）在目标检测和实例分割中被广泛应用，是定位目标的重要步骤。然而，大多数现有的边界框回归损失函数在预测框与实际标注框具有相同的宽高比但宽度和高度值完全不同的情况下无法进行优化。

博客

最新SOTA！基于4D成像雷达和相机融合的3D目标检测新基线

08-18

168

最近，一些工作将 “采样法（sampling）” 策略应用于图像视图变换，并表明即使没有图像深度估计，它也优于 “溅射法” 。

博客

ICCV 2023 Random Boxes Are Open-world Object Detectors 论文解读

08-17

376

目标检测是计算机视觉的基础任务之一,目的是给图像中的目标对象定位和分类。

博客

动态环境下竟然能在嵌入式系统上实现实时语义RGB-D SLAM？？

08-16

137

大多数现有的视觉SLAM方法严重依赖于静态世界假设，在动态环境中很容易失效。本文提出了一个动态环境下的实时语义RGB-D SLAM系统，该系统能够检测已知和未知的运动物体。

博客

Meta最新开源！跟踪一切升级版！性能超越OmniMotion！

08-15

228

最近几个月，CV界真是跟“一切”杠上了。先是Meta在4月5日发布了Segment Anything，可以为任何图像中的任何物体提供Mask。

博客

ROSpider机器人评测报告

08-14

986

在“蜘蛛”身体的上方装有Astra Pro深度相机，是ROSpider机器人的眼睛，它可以进行水平方向的旋转以及上下角度的变换

博客

S1机器人评测报告

08-14

231

在机器人基础3D视觉应用端我们首先对该机器人的线条和色块的识别和追踪功能进行了测试，并用OpenCV视觉实现KCF算法。

博客

一文搞定opencv中常见的关键点检测算法(附代码)

08-14

283

角点时图像中存在物体边缘角落位置的点或者一些特殊位置的点，角点检测(Corner Detection)是计算机视觉系统中获取图像特征的一种方法，是运动检测、图像匹配、视频跟踪、三维重建和目标识别的基础。

“相关推荐”对你有帮助么？

非常没帮助

没帮助

一般

有帮助

非常有帮助

提交

奥比中光3D视觉开发者社区

CSDN认证博客专家

CSDN认证企业博客

原创

3532

周排名

6万+

总排名

51万+

访问

等级

2622

积分

1万+

粉丝

721

获赞

293

3145

私信

关注

最新文章

Q-YOLO：用于实时目标检测的高效推理

一种在终端设备上用量化和张量压缩的紧凑而精确的视频理解

Yolo框架大改 | 消耗极低的目标检测新框架

2023年75篇

2022年167篇

2021年38篇

2020年50篇

分类专栏

开发者

146篇

3D视觉

144篇

结构光

60篇

机构光

1篇

【奥比中光3D视觉创新应用竞赛优秀作品】

8篇

SDK

1篇

被折叠的条评论

为什么被折叠?

到【灌水乐园】发言

查看更多评论

添加红包

祝福语

请填写红包祝福语或标题

红包数量

个

红包个数最小为10个

红包总金额

元

红包金额最低5元

余额支付

当前余额3.43元

前往充值 >

需支付：10.00元

取消

确定

下一步

知道了

成就一亿技术人!

领取后你会自动成为博主和红包主的粉丝

规则

hope_wisdom 发出的红包

实付元

使用余额支付

点击重新获取

扫码支付

钱包余额

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值

Oracle Optimizer -RBO (理解Rule-based 优化器)-CSDN博客

Oracle Optimizer -RBO (理解Rule-based 优化器)

最新推荐文章于 2020-11-03 11:29:18 发布

cuanxiu7017

最新推荐文章于 2020-11-03 11:29:18 发布

阅读量263

点赞数

/*理解Rule-based 优化器 RBO 优先使用预定义方法去计算使用的某条路径访问数据库资料. RDBMS 使用下列条件则优先选择RBO的优化器.包括:在init.ora 文件中设定OPTIMIZER_MODE = RULE 在init.ora 文件中设定OPTIMIZER_MODE = choose,并且在SQL 中所包含的Table 没有统计资料. 在Session 中使用 alter session set optimizer_mode=rule 在Session 中使用 Alter session set optomizer_mode=Choose 命令,并且SQL 中的任何table 都没有统计资料 Rule hint (例如 select /*+RULE*/....) 在SQL 中强制使用RBO*/ ---RBO rule-based optimizer--(EMP_NO,EMP_NAME,EMP_CLASS,DEPT_NO,EMP_CATEGORY,COST_CENTER)

--Case 1: (In fact, only the two-column index is used; -- the single-column index is not used. While Oracle will merge two single-column indexes, -- it will not merge a multi-column index with another index. )

ALTER session SET optimizer_mode=rule ;

CREATE INDEX idx_1 ON emp(dept_no) ; CREATE INDEX idx_2 ON emp(emp_no,emp_name); SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_no = 2 AND emp_name = 'PJWANG' AND dept_no = '12' ---未Create Index 时 -- Execution Plan---------------------------------------------------------- -- 0 SELECT STATEMENT Optimizer=RULE -- 1 0 TABLE ACCESS (FULL) OF 'EMP'

-- Create index idx_1 (dept_no) --( 上面SQL where subclause 怎么组合都会用到 Idx_1) CREATE INDEX idx_1 ON emp(dept_no) ; --Execution Plan---------------------------------------------------------- -- 0 SELECT STATEMENT Optimizer=RULE -- 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP' -- 2 1 INDEX (RANGE SCAN) OF 'IDX_1' (NON-UNIQUE)

CREATE INDEX idx_2 ON emp(emp_no,emp_name); --(上面的SQL 语句会用到idx_2,因为Idx_2 的columns 比较多且接近Where 后面的栏位) --Execution Plan------------------------------------------------------------ 0 SELECT STATEMENT Optimizer=RULE-- 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'-- 2 1 INDEX (RANGE SCAN) OF 'IDX_2' (NON-UNIQUE)

--Case 2:---(如果index不是所有Column 在where 子句中,sql 则选择一些Column 在同一个Index 中的Index) --( Lis: 如果index 中的所有栏位在SQL 上,那肯定选择此index,如果此index 包含其他栏位,而这些栏位没有在 -- SQL 中.则SQL 选择Where 条件后尽可能多的栏位在同一个Index's index) CREATE INDEX idx_3 ON emp(emp_no,emp_name,dept_no,cost_center); /* SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_no = 2 AND emp_name = 'PJWANG' AND dept_no = '12' --AND cost_center='RD Center' */ -- Execution Plan------------------------------------------------------------ 0 SELECT STATEMENT Optimizer=RULE-- 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'-- 2 1 INDEX (RANGE SCAN) OF 'IDX_2' (NON-UNIQUE) --Idx_3

--Case 3: (多个Index 都包含 Where 相同个数的Column,则SQL 选择最后一个创建的index) -- CREATE INDEX idx_2 ON emp(emp_no,emp_name); --drop index idx_3. CREATE INDEX idx_4 ON emp(dept_no,cost_center); --(idx_2,idx_4 的栏位都在SQL 中,且个数相同,且不会因为Where 后面Column 顺序改变而选择不同的Index) -- Execution Plan------------------------------------------------------------ 0 SELECT STATEMENT Optimizer=RULE-- 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'-- 2 1 INDEX (RANGE SCAN) OF 'IDX_4' (NON-UNIQUE)

---Case 4: (如果Where 子句中的多个Column 在不同的 Index 中, "=" 操作的Index 将替换如Like,between 之类的Index) CREATE INDEX idx_3 ON emp(emp_no,emp_name,dept_no,cost_center); SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_no = 2 AND emp_name LIKE 'PJWAN%' AND dept_no = '12' AND cost_center='RD Center'----Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP' 2 1 INDEX (RANGE SCAN) OF 'IDX_4' (NON-UNIQUE)

----如果是Between 则 SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_no = 2 AND emp_name = 'PJWANG' AND dept_no BETWEEN '12' AND '20' AND cost_center='RD Center'--Execution Plan------------------------------------------------------------ 0 SELECT STATEMENT Optimizer=RULE-- 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'-- 2 1 INDEX (RANGE SCAN) OF 'IDX_2' (NON-UNIQUE)

----如果全部是"=" SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_no = 2 AND emp_name = 'PJWANG' AND dept_no = '12' AND cost_center='RD Center'--Execution Plan------------------------------------------------------------ 0 SELECT STATEMENT Optimizer=RULE-- 1 0 INDEX (RANGE SCAN) OF 'IDX_3' (NON-UNIQUE)

--Case 5:( where 子句的多个栏位在不同的index 中,则Where 子句中Column 在Index 占Index 所有column 的百分率高的会被采用) --( 所有Index 中的栏位都没有全部被Where 子句包含) -- drop index idx_2; --drop index idx_1; CREATE INDEX idx_5 ON emp(emp_no,emp_category); -- CREATE INDEX idx_3 ON emp(emp_no,emp_name,dept_no,cost_center); SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_no = 2 AND emp_name = 'PJWANG' AND dept_no='12' AND emp_class='IE'

--百分率不同: idx_3=(emp_no+emp_name+dept_no)/4=75% -- idx_5=(emp_no)/2=50%Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP' 2 1 INDEX (RANGE SCAN) OF 'IDX_3' (NON-UNIQUE)

--- 百分率相同则选最后一个创建的: idx_3=(emp_no+emp_name)/4=50% -- idx_5=(emp_no)/2=50%

SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_no = 2 AND emp_name = 'PJWANG' AND emp_category='HI1' Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP' 2 1 INDEX (RANGE SCAN) OF 'IDX_5' (NON-UNIQUE) --Case 6: (如果两个Index 包含相同的Column ,SQL在使用时会使用和Where 后面第一个Column 相同并且是index第一个column的 index) -- CREATE INDEX idx_5 ON emp(emp_no,emp_category); CREATE INDEX idx_6 ON emp( emp_category,emp_no); SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_no = 2

--此SQL 的第一个栏位在Idx_5 中是第一个,则选中idx_5--Execution Plan------------------------------------------------------------ 0 SELECT STATEMENT Optimizer=RULE-- 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'-- 2 1 INDEX (RANGE SCAN) OF 'IDX_5' (NON-UNIQUE)

SELECT emp_no,DEPT_NO,COST_CENTER FROM emp WHERE emp_category='HI1'

--此SQL 的第一个栏位在Idx_6 中是第一个,则选中idx_6--Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP' 2 1 INDEX (RANGE SCAN) OF 'IDX_6' (NON-UNIQUE) [@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/34596/viewspace-797998/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/34596/viewspace-797998/

优惠劵

cuanxiu7017

关注

踩

觉得还不错?

一键收藏

知道了

Oracle Optimizer -RBO (理解Rule-based 优化器)

/*理解Rule-based 优化器 RBO 优先使用预定义方法去计算使用的某条路径访问数据库资料. RDBMS 使用下列条件则优先选择RBO的优化器.包括:在init.ora 文件中设定OPTIMIZER_...

复制链接

扫一扫

craco-image-optimizer-plugin:craco图像优化器插件

05-04

Craco图像优化器这是插件。使用image-webpack-loader的优化器安装 # npm $ npm install craco-image-optimizer-plugin # yarn $ yarn add craco-image-optimizer-plugin 用法我们正在使用image-webpack-loader...

Oracle 里的优化器

u011868279的博客

01-29

1921

Oracle 里的优化器

参与评论

您还未登录，请先

后发表或查看评论

Oracle数据库的配置和SQL语句的优化 /*+ rule */ & INSERT/*+append*/INTO

caihorse的专栏

06-27

4024

Oracle数据库的配置和SQL语句的优化。

INSERT/*+append*/INTO t_servicexx(serviceid,clientid,prod_id,serviceno,addrid, connectno,fgsid,gl_serviceid,up_serviceid,servlev, ...

基于RULE的优化器（学习笔记）

Mr.pan felix的专栏

02-03

2508

崔华《基于Oracle的sql优化》学习笔记

1.1 基于RULE的优化器

(1) CBO

(2)RBO

和CBO相比，RBO是有其明显权限的。在使用RBO的情况下，执行计划一旦出了问题，很难对其做调整。另外，如果使用了RBO则目标SQL的写法，甚至是目标SQL中所涉及的各个对象在该SQL文本中出现的先后顺序都可能影响RBO执行计划的选择我，更糟糕的是，Oracle数据库中很好的特性...

Using the Rule-Based Optimizer

sstevencao的专栏

08-06

315

Although Oracle supports the rule-based optimizer, you should design new

applications to use the cost-based optimizer (CBO). You should also use

the CBO for data warehousing applications, becaus...

基于规则的优化器

天行健君子以自强不息

01-12

1009

1、优化器是oracle数据库中内置的一个核心子系统，也可以把它理解成是oracle数据库中的一个核心的模块或者一个核心功能组件，

优化器的目的是为了得到目标sql的执行计划

2、oracle数据库里的优化器又分为RBO和CBO这两种类型。

3、RBO所用的判断原则为一组内置的规则，这些规则是硬编码在oracle数据库的代码中的，RBO会根据这些规则从目标sql诸多可能的执行

pytorch-optimizer:torch-optimizer -- Pytorch 优化器的集合

07-23

火炬优化器 torch-optimizer -- 与模块兼容的优化器集合。简单的例子 import torch_optimizer as optim# model = ...optimizer = optim . DiffGrad ( model . parameters (), lr = 0.001 )optimizer . step ()安装...

win11系统优化器+win10系统优化器+Optimizer-14.5

12-15

根据Windows版本的不同，优化器还允许您执行一些特定的调整。支持 Windows10/11 软件特点：全语言支持（提供19种语言）；提高系统和网络性能；禁用不必要的窗口服务；禁用 Windows 遥测、小娜等；禁用办公室遥测...

torch-optimizer -- Pytorch的优化器集合-python

06-18

torch-optimizer -- collection of optimizers for Pytorchtorch-optimizer torch-optimizer -- 与 optim 模块兼容的 PyTorch 优化器集合。简单示例 import torch_optimizer as optim # model = ... optimizer = ...

genshin-optimizer:用于Genshin Impact的工件优化器

03-18

npm test在交互式监视模式下启动测试运行器。有关更多信息，请参见关于的部分。npm run build构建生产到应用程序build文件夹。它在生产模式下正确捆绑了React，并优化了构建以获得最佳性能。生成被最小化，并且...

数据库基于规则优化(RBO)和基于代价优化(CBO)

djm82755的博客

06-21

1722

RBO和CBO是两种数据库引擎在执行sql语句时的优化策略。

什么是基于规则的优化(Rule Based Optimizer)?

这是一种比较老的技术，简单说基于规则的优化就是当数据库执行一条query语句的时候必须遵循预先定义好的一系列规则（比如oracle的15条规则，排名越靠前的执行引擎认为效率越高https://docs.oracle.com/cd/B10501_01/...

Oracle的优化器有两种优化方式(一)

java3344520的专栏

04-15

4684

Oracle的优化器有两种优化方式(整理), 2010-04-13RBO方式：基于规则的优化方式(Rule-Based Optimization，简称为RBO) 优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则。比如我们常见的，当一个where子句中的一列有索引时去走索引。 CBO方式：基于代价的优化方式(Cost-Based Optimization，简称为CBO)它是看

oracle 四种优化模式 Rule、Choose、First rows、All rows

linli1991的博客

03-12

1万+

Oracle的优化器有两种优化方式,即基于规则的优化方式(Rule-Based Optimization，简称为RBO)和基于代价的优化方式(Cost-Based Optimization，简称为CBO)，在Oracle8及以后的版本,Oracle强列推荐用CBO的方式 RBO方式：优化器在分析语句时,所遵循的是Oracle内部预定的一些规则。比如我们常见的，当一个where子句中的一列有索...

SQL 物理逻辑优化，Volcano Optimizer

weixin_45875458的博客

11-03

662

SQL 查询优化的目的

优化器在整个数据库系统中占据着至高无上的地位，它是数据库性能的决定因素，是所有数据库引擎中最重要的组件。

⑴使用的角度

因为SQL 是一种声明式(Declarative)的编程语言，相比一般的编程语言描述的是程序执行的过程，这类编程语言则是描述问题或者需要的结果本身，具体的执行步骤则交由程序自己决定。SQL是一种可以被快速入手的编程语言，主要优点就在于即使用户因并不了解数据库内部的实现细节而写出来十分糟糕的查询语句，只要表达的意思准确清楚，数据库就可以返回结果。因此必须对SQL

浅谈optimizer_mode优化器模式

ciqu9915的博客

08-16

246

Oracle query optimizer（查询优化器）是我们接触最多的一个数据库组件。查询优化器最主要的工作就是接受输入的SQL以及各种环境参数、配置参数，生成合适的SQL执行计划（Execution Plan）。

...

【数据库】优化器(optimizer)

weixin_34163741的博客

01-12

364

optimizer is the core of a DB engine!

实际运行计划(physical plan) = 访问方式 ( access method) + join算法 + 执行顺序

1.access method

1) index scan

2) file scan

2.join algorithm

1) nested-loop

2) has...

Oracle优化器三大种类的介绍

weixin_30532973的博客

05-08

151

Oracle优化器一共有三种即，RULE (基于规则)，COST (基于成本)以及CHOOSE (选择性)，我们大家都知道设置缺省的相关Oracle优化器，其可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明。

　　如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖。

　　为了使用...

Oracle RBO、CBO简介

最新文章

Oracle 12c RAC: MGMTDB

oracle RAC RDS on AIX

ocssd.log filesize >50M

2017年2篇

2016年13篇

2015年5篇

2014年6篇

2013年10篇

2012年3篇

2011年6篇

2010年58篇

2009年38篇

2008年6篇

2007年8篇

2006年20篇

2005年25篇

2004年4篇

最新文章

Oracle 12c RAC: MGMTDB

oracle RAC RDS on AIX

ocssd.log filesize >50M

2017年2篇

2016年13篇

2015年5篇

2014年6篇

2013年10篇

2012年3篇

2011年6篇

2010年58篇

2009年38篇

2008年6篇

2007年8篇

2006年20篇

2005年25篇

2004年4篇

被折叠的条评论

为什么被折叠?

到【灌水乐园】发言

查看更多评论

添加红包

祝福语

请填写红包祝福语或标题

红包数量

个

红包个数最小为10个

红包总金额

元

红包金额最低5元

余额支付

当前余额3.43元

前往充值 >

需支付：10.00元

取消

确定

下一步

知道了

成就一亿技术人!

领取后你会自动成为博主和红包主的粉丝

规则

hope_wisdom 发出的红包

实付元

使用余额支付

点击重新获取

扫码支付

钱包余额

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值

RBO是什么意思? - RBO的全称 | 在线英文缩略词查询

↓ 跳到主内容

EnglishالعربيةБългарскиCatalàČeštinaCymraegDanskDeutschΕλληνικάEspañolEestiفارسیSuomiFrançaisעִבְרִיתहिन्दीJezikAyititMagyarBahasa IndonesiaItaliano日本語한국어LietuviųLatviešuMelayuMaltiNorskNederlandsPolskiPortuguêsRomânăРусскийSlovenčinaslovenščinaSvenskaไทยTürkçeукраїнськаاردوViệt Nam繁體中文

首页 › 3 个字母 › RBO

RBO 是什么意思?

你在寻找RBO的含义吗？在下图中，您可以看到RBO的主要定义。如果需要，您还可以下载要打印的图像文件，或者您可以通过Facebook，Twitter，Pinterest，Google等与您的朋友分享。要查看RBO的所有含义，请向下滚动。完整的定义列表按字母顺序显示在下表中。

RBO的主要含义

下图显示了RBO最常用的含义。您可以将图像文件下载为PNG格式以供离线使用，或通过电子邮件发送给您的朋友。如果您是非商业网站的网站管理员，请随时在您的网站上发布RBO定义的图像。

RBO的所有定义

如上所述，您将在下表中看到RBO的所有含义。请注意，所有定义都按字母顺序列出。您可以单击右侧的链接以查看每个定义的详细信息，包括英语和您当地语言的定义。

首字母缩写词定义RBO人民币业务对象RBO住宅建筑官员RBO俄勒冈州罗斯堡市RBO修复故障后方可经营RBO全向无线电信标RBO区域分支机构RBO半径的休息RBO基于可靠度的优化RBO基于规则的优化程序RBO岩石等美女 OreillesRBO巴西 de OrnitologiaRBO度假村的商机RBO摄制学会组织RBO救助艇操作员RBO河流域组织RBO注册平衡优化RBO注册建筑官员RBO皇家泡沫乐团RBO稳压器烧坏RBO米糠油RBO魔戒战斗脱机

‹ RBAC

RCOT ›

语言

简体中文

SQL优化-RBO（Rule-Based Optimization） - 掘金

首页首页

沸点

课程

直播

活动

竞赛

商城

APP

插件搜索历史

清空

创作者中心

写文章发沸点写笔记写代码草稿箱创作灵感

会员

SQL优化-RBO（Rule-Based Optimization）

KaiwuDB

2022-08-26

277

优化器是 KaiwuDB 中的一个核心的模块，KaiwuDB 使用优化器来完成对 SQL 语句优化并得到最优的逻辑计划，KaiwuDB 里的优化器分为 RBO 和 CBO 两个阶段。

RBO 是基于规则的优化，这些规则背后的原理是关系代数的等价变换，其中典型的规则包括：列剪裁，谓词下推等。RBO 将内置的规则作为优化的基础，同时这些规则是硬编码在 KaiwuDB 的代码中的，RBO 会根据这些规则从目标 SQL 诸多可能的代数转换中选择一条来作为逻辑计划。

KaiwuDB 的 RBO 优化器采用了 Optgen 语言编写，它提供了一种直观的语法来定义、匹配和替换目标表达式树中的节点。优化器规则的编写便是基于这种语言，使用 Optgen 语言可以很容易实现 RBO 规则。

KaiwuDB 的 RBO 规则实现如下图所示，①被称为匹配模式，②被称为替换模式，优化器规则是某表达式满足①模式，然后转化为②模式的表达式。

①的匹配模式又分为三部分，第一部分中括号内是规则的名称，在 Opt 文件编译时会作为规则的标识，第二部分是第二行左小括号后位规则作用域，在 KaiwuDB 内有明确的类型划分。编写规则时要清楚这条规则是针对哪种类型表达式发生作用，第三部分是剩下的规则部分，是规则的匹配条件。

模式①匹配条件是等值表达式，左孩子不是变量，右孩子是变量。这里的 NormalizeEq 是名称，Eq 是规则类型，针对等值表达式。模式②表示新构建一个等值表达式，只是与原表达式相比，左右孩子互换。示例：1=a => a=1

KaiwuDB 内置了上百种 RBO 规则，支持大量的 SQL 语句的代数优化，包括传统的列裁剪、最大最小消除、投影消除、谓词下推等等，也包括一些复杂的 Join 等下推操作。TryDecorrelateGroupBy，这个规则的 OptGen 规则描述如下：

[TryDecorrelateGroupBy, Normalize]

(InnerJoin | InnerJoinApply

$left:*

$right:* &

(HasOuterCols $right) &

(GroupBy | DistinctOn

$input:*

$aggregations:*

$groupingPrivate:*

) &

(IsUnorderedGrouping $groupingPrivate)

$on:*

$private:*

)

(Select

((OpName $right)

(InnerJoinApply

newLeft:(EnsureKeynewLeft:(EnsureKey newLeft:(EnsureKeyleft)

$input

[]

$private

)

(AppendAggCols

$aggregations

ConstAgg (NonKeyCols $newLeft)

)

(AddColsToGrouping groupingPrivate(KeyColsgroupingPrivate (KeyCols groupingPrivate(KeyColsnewLeft))

)

$on

)

TryDecorrelateGroupBy 主要作用在 InnerJoin | InnerJoinApply 操作中，它将 Join“下推”到 GroupBy 运算符中，以尝试继续“挖掘”以找到并消除不必要的相关性。最终的希望是触发 DecorrelateJoin 规则，将 JoinApply 操作符转换为非 Apply Join 操作符。

SELECT left.x, left.y, input.*

FROM left

INNER JOIN LATERAL

(

SELECT COUNT(*) FROM input WHERE input.x = left.x GROUP BY c

) AS input

ON left.y = 10

SELECT CONST_AGG(left.x), CONST_AGG(left.y), COUNT(*)

FROM left WITH ORDINALITY

INNER JOIN LATERAL

(

SELECT * FROM input WHERE input.x = left.x

) AS input

ON True

GROUP BY input.c, left.ordinality

HAVING left.y = 10

KaiwuDB 采用了 Optgen 语言作为 RBO 规则的编写语言，通过上面的例子可以看出，按照既定模式添加完善 RBO 规则十分便捷，通过编译可以将规则嵌入到系统 RBO 规则框架中；后续会有更深入的关于 RBO 使用框架与大家分享，敬请期待！

KaiwuDB

@KaiwuDB

135

文章

21k

阅读

粉丝目录收起相关推荐大促场景下库存更新 SQL 优化 31k阅读 · 80点赞为什么面试官这么爱问性能优化？ 71k阅读 · 1.2k点赞让SQL起飞（优化） 17k阅读 · 312点赞2023 前端性能优化清单 43k阅读 · 848点赞URule规则引擎 4.8k阅读 · 35点赞友情链接：

action java

Follow

比特派钱包app下载|rbo

比特派钱包app下载|rbo

简单了解CBO、RBO、HBO - 知乎

SQL优化器-RBO与CBO分别是什么 - JasonCeng - 博客园

数据库查询优化器，RBO优化规则介绍及示例-CSDN博客

半导体封装胶粘剂简介（18）-树脂溢出现象RBO - 知乎

ORACLE优化器RBO与CBO介绍总结 - 潇湘隐者 - 博客园

数据库内核-CBO 优化器基本概念 - 知乎

RGBD相机参数输出定义_d2c深度-CSDN博客

Oracle Optimizer -RBO (理解Rule-based 优化器)-CSDN博客

RBO是什么意思? - RBO的全称 | 在线英文缩略词查询

SQL优化-RBO（Rule-Based Optimization） - 掘金

最近的新闻

您可能喜欢的文章

tokenpocket钱包官方网站|qqc

tp安卓官方版|shopify

比特派官方客服电话是多少

比特派官方客服电话多少

比特派有客服电话吗多少

比特派的客服电话是多少

比特派批量转账矿工费多少