CBO RBO

2024-09-07 00:08
文章标签 cbo rbo

本文主要是介绍CBO RBO,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!


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对其了解得比较深入。

CBO是一种比RBO更加合理、可靠的优化器,它是从ORACLE 8中开始引入,但到ORACLE 9i 中才逐渐成熟,在ORACLE 10g中完全取代RBO, CBO是计算各种可能“执行计划”的“代价”,即COST,从中选用COST最低的执行方案,作为实际运行方案。它依赖数据库对象的统计信息,统计信息的准确与否会影响CBO做出最优的选择。如果对一次执行SQL时发现涉及对象(表、索引等)没有被分析、统计过,那么ORACLE会采用一种叫做动态采样的技术,动态的收集表和索引上的一些数据信息。

关于RBO与CBO,我有个形象的比喻:大数据时代到来以前,做生意或许凭借多年累计下来的经验(RBO)就能够很好的做出决策,跟随市场变化。但是大数据时代,如果做生意还是靠以前凭经验做决策,而不是靠大数据、数据分析、数据挖掘做决策,那么就有可能做出错误的决策。这也就是越来越多的公司对BI、数据挖掘越来越重视的缘故,像电商、游戏、电信等行业都已经大规模的应用,以前在一家游戏公司数据库部门做BI分析,挖掘潜在消费用户简直无所不及。至今映像颇深。


CBO优化器组件

CBO由以下组件构成:

· 查询转化器(Query Transformer)

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

· 代价评估器(Estimator)

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

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

· 计划生成器(Plan Generator)

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

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


CBO优化器有两种可选的运行模式:

FIRST_ROWS(n)

ALL_ROWS

当设置优化器模式为:FIRST_ROWS(n)时,意味着Oracle在执行SQL语句时,优先考虑将结果集中的前n条记录以最快的速度反馈回来,而其他结果并不需要同事反馈,也就是说在处理数据的时候,后面的数据可能还没提取出来,前面的数据已经返回给用户了,这种需求在网站搜索或者BBS的分页上经常看到。比如每次只显示查询信息的前20条,这时设置FIRST_ROWS(20)就非常合适。对于分页操作,越靠前的页,显示结果需要的时间将越短。

下面举一个典型的分页的例子:

idle> select /*+first_rows(10)*/ b.x,b.y

  2  from (select /*+first_rows(10)*/ a.*,rownum

  3        from (select /*+first_rows(10)*/ from t order by x) a

  4        where rownum<=20) b

  5  where rownum>=10;

需要注意的是排序使用的X必须创建有索引,否则CBO会忽略FIRST_ROWS(n)而使用ALL_ROWS.

CBO的模式为ALL_ROWS时,意味着我们需要Oracle以最快的速度将SQL执行完毕,将结果集全部返回。它和FIRST_ROWS(n)的区别在于,ALL_ROWS强调整体的执行效率,而FIRST_ROWS(n)强调以最快的速度返回前n条记录。ALL_ROWS在OLAP系统中使用的比较多,它的目的在于快速获取执行结果的最后一条记录。

可以通过下面语句修改optimizer_mode

alter system set optimizer_mode=all_rows scope=both;



这篇关于CBO RBO的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1143502

相关文章

11GR2下基于CBO全表扫描cost计算

########################################################## ##11gr2下基于cbo优化器,在不做系统统计信息收集下全表扫描的成本计算#### ########################################################## CBO的成本计算设计到非工作负载下的系统统计信息 CPUSPEEDNW=>系统

CEO CFO CIO CTO CKO CHO CMO CNO CQO CBO CCO CVO 英文定义

CEO CFO CIO CTO CKO CHO CMO CNO CQO CBO CCO CVO 英文定义 CEO:Chief Executive Officer 首席执行官 CFO:Chief Financial Officer 首席财务官 CIO:Chief Information Officer 首席信息官 CTO:Chief Technology Officer 首席技术官 CKO:Chi

openGauss CBO优化器

CBO优化器 可获得性 本特性自openGauss 1.0.0版本开始引入。 特性简介 openGauss优化器是基于代价的优化(Cost-Based Optimization,简称CBO)。 客户价值 openGauss CBO优化器能够在众多计划中依据代价选出最高效的执行计划,最大限度的满足客户业务要求。 特性描述 在CBO优化器模型下,数据库根据表的元组数、字段宽度、NULL

在使用RBO的情况下,出现两条或两条以上的执行路径的等级值相同的情况下,如何调整执行计划?

如果在目标SQL中使用了hint,就意味着自动启用了CBO(仅有两个例外),那如何在使用RBO的情况下对执行计划做调整呢? 1、等价改写目标SQL 比如在SQL的where条件中对number或date类型的列加上0,在varchar2或char上加上空字符串,例如||'',这样就可以让原本可以走的索引走不了。 2、通过调整索引在数据字典缓存中的缓存顺序来改变执行计划 会优先使用后创建(创

spark sql基于CBO的优化

前言 spark sql基于CBO的优化是建立在物理计划层面的,原理是计算出所有可能的物理执行计划,并挑选成代价最小的物理执行计划。对于执行计划可以去看我的另一篇博客RBO优化 CBO的话主要用来调整inner join所涉及表的顺序 使用CBO准备 搜集所需表和列的统计信息 生成表级别的统计信息 ANALYZE TABLE 表名 COMPUTE STATISTICS生成列级别的统计信息

查询优化器:RBO与CBO

SQL查询优化器 1、数据库系统发展简史2、SQL查询优化器3、查询优化器分类4、查询优化器执行过程5、CBO框架Calcite简介 1、数据库系统发展简史 数据库系统诞生于20世纪60年代中期,至今已有近50多年的历史,其发展经历了三代演变,造就了四位图灵奖得主,并发展成为一门计算机基础学科,带动了一个巨大的软件产业 20世纪60年代后期出现了一种新型数据库

2021-03-23转发《ORACLE CBO 的 SQL 自动转换(Cost Based Transformations)之一》

我用#CSDN#这个app发现了有技术含量的博客,小伙伴们求同去《ORACLE CBO 的 SQL 自动转换(Cost Based Transformations)之一》, 一起来围观吧 https://blog.csdn.net/weixin_50513167/article/details/115124637?utm_source=app&app_version=4.5.5

hive cbo优化引起的bug

hive.stats.fetch.column.stats导致reduce个数划分太小 有一个任务,在混部集群默认开启,导致任务reduce个数太小,只启了2个reducetask,而maptask中读取的数据又很大,使得大量数据都写到这2个reduce task中,任务最终失败,在关闭这个参数后,可以启动1100个reducetask。 怎么发现这个问题的: 对比执行计划,在开启这个参数后,h

MySQL调优学习笔记(四):MySQL优化器(CBO)

目录 MySQL优化器(CBO) mysql索引一般建立在高选择性字段上,也有例外 总结 参考资料:姜承尧的MySQL实战宝典 MySQL优化器(CBO) MySQL优化器决定了具体某一索引的选择,也就是常说的执行计划。优化器的选择是基于成本,它会分析所有可能的执行计划,哪个索引的成本越低,优先使用哪个索引。这种优化器称之为:CBO(Cost-based Optimizer,基于成本的