读书笔记-《基于Oracle的SQL优化》-第一章-3

简介: 优化器:1、优化器的模式:用于决定在Oracle中解析目标SQL时所用优化器的类型,以及决定当使用CBO时计算成本值的侧重点。这里的“侧重点”是指当使用CBO来计算目标SQL各条执行路径的成本值时,计算成本值的方法会随着优化器模式的不同而不同。
优化器:
1、优化器的模式:
用于决定在Oracle中解析目标SQL时所用优化器的类型,以及决定当使用CBO时计算成本值的侧重点。这里的“侧重点”是指当使用CBO来计算目标SQL各条执行路径的成本值时,计算成本值的方法会随着优化器模式的不同而不同。
Oracle中,优化器的模式是由参数OPTIMIZER_MODE的值来决定的。
RULE:表示Oracle将使用RBO来解析目标SQL,此时SQL中涉及的各个对象的统计信息对于RBO没有任何作用。
CHOOSE:Oracle 9i的默认值,表示RBO还是CBO取决于SQL涉及的表对象是否有统计信息。
FIRST_ROWS_n(n=1,10,100,1000):此时CBO计算SQL的各条执行路径的成本值时的侧重点在于以最快的响应速度返回头n(n=1,10,100,1000)条记录。
FIRST_ROWS:Oracle 9i中就已经过时的参数,当一些特殊情况下的时候,会使用RBO中的一些内置的规则来选取执行计划不再考虑成本。例如当发现能用相关的索引来避免排序,则会选择索引对应的执行路径不再考虑成本,显然是不合理的。这时,索引全扫描的概率比以前有所增加,因为用索引全扫描能避免排序。
ALL_ROWS:Oracle 10g及以后版本中OPTIMIZER_MODE的默认值,表示使用CBO解析目标SQL,此时CBO计算SQL的各条执行路径的成本值时的侧重点在于最佳的吞吐量(即最小的系统I/O和CPU资源的消耗量)。

2、结果集:
指包含指定执行结果的集合。对RBO来说,对应的执行计划中没有对相关执行步骤对应的结果集的描述,虽然结果集的概念对RBO也是适用的。对CBO来说,对应执行计划中的列(Rows)反映的就是CBO对应相关执行步骤所对应的输出结果集的记录数(Cardinality)的估算值。

3、访问数据的方法:
3.1 访问表的方法
全表扫描:
指Oracle访问目标表里的数据时,会从该表所占用的第一个区(Extent)的第一个块(Block)开始扫描,一直扫描到该表的高水位线(HWM),这段范围内所有的数据块都必须读到。
ROWID扫描:
指Oracle访问目标表里的数据时,直接通过数据所在的ROWID定位并访问这些数据。ROWID表示Oracle中的数据行记录所在的物理存储地址,也就是说ROWID实际上和Oracle中数据块里的行记录一一对应的。
ROWID扫描有两层含义:一种是根据用户在SQL语句中输入的ROWID的值直接访问对应的数据行记录;另外一种是先访问相关的索引,然后根据访问索引后得到的ROWID再回表访问对应的数据行记录。
对Oracle堆表而言,通过Oracle内置的ROWID伪列得到对应航记录所在的ROWID的值(注意:ROWID只是一个伪列,在实际的表块中并不存在该列),然后还可以根据DBMS_ROWID包中的相关方法(dbms_rowid.rowid_relative_fno、dbms_rowid.rowid_block_number和dbms_rowid.rowid_row_number)将上述ROWID伪列的值翻译成对应数据行的实际物理存储地址。
访问索引的方法:
(1)、索引唯一性扫描:INDEX UNIQUE SCAN,仅适用于where条件中是等值查询的目标SQL。因为扫描的对象是唯一性索引,所以索引唯一性扫描的结果至多只会返回一条记录。
(2)、索引范围扫描:INDEX RANGE SCAN,当扫描的对象是唯一性索引时,目标SQL的where条件一定是范围查询(谓词条件为BETWEEN、<、>等);当扫描的对象是非唯一性索引时,对目标SQL的where条件没有限制(可以是等值查询,也可以是范围查询)。
在同等条件下,当目标索引的索引行的数量大于1时,索引范围扫描所耗费的逻辑读至少会比相应的索引唯一性扫描多1。
(3)、索引全扫描:指要扫描目标索引所有叶子块的所有索引行。但并不意味着需要扫描该索引的所有分支块。默认情况下,Oracle在做索引全扫描时只需要通过访问必要的分支块定位到位于该索引最左边的叶子块的第一行索引行,就可以利用该索引叶子块之间的双向指针链表,从左至右依次顺序扫描该索引所有叶子块的所有索引行了。
按照索引键值顺序排序,即可达到排序的效果。避免真正的排序。
默认情况下,索引全扫描的有序性就决定了所以全扫描不能并行执行,通常使用单块读。
做索引全扫描的前提条件是目标索引至少有一个索引键值列的属性是NOT NULL。
索引快速全扫描:INDEX FAST FULL SCAN,需要扫描目标索引所有叶子块的所有索引行。
与索引全扫描的区别:
(1)、索引快速全扫描只适用于CBO。
(2)、索引快速全扫描可以使用多块读,也可以并行执行。
(3)、索引快速全扫描结果不一定是有序的。因为索引快速全扫描时Oracle是根据索引行在磁盘上的物理存储顺序来扫描,而不是根据索引行的逻辑顺序来扫描的。所以扫描结果才不一定有序(对于单个索引叶子块中的索引行而言,其物理存储顺序和逻辑存储顺序一致,但对于物理存储位置相邻的索引叶子块而言,块与块之间索引行的物理存储顺序则不一定在逻辑上有序。
索引跳跃式扫描:INDEX SKIP SCAN,它使那些在where条件中没有对目标索引的前导列指定查询条件但同时又对该索引的非前导列指定了查询条件的目标SQL依然可以用上该索引,这就像在扫描该索引时跳过了它的前导列。这是因为Oracle帮你对该索引的前导列的所有distinct值做了遍历。
Oracle中的索引跳跃式扫描仅适用于那些目标索引前导列的distinct值数量较少,后续非前导列的可选择性又非常好的情形,因为索引跳跃式扫描的执行效率一定会随着目标索引前导列的distinct值数量的递增而递减。

表连接
当优化器解析含表连接的目标SQL时,它除了会根据目标SQL的SQL文本的写法来决定表连接的类型之外,还必须决定如下三件事情才能得到最终的执行计划。
(1)、表连接顺序
(2)、表连接方法
(3)、访问单表的方法

表连接类型:
(1)、内连接
只要where条件中没有写那些标准SQL中定义或者Oracle中自定义的表示外连接的关键字,则该SQL的连接类型就是内连接。
标准SQL中内连接的写法是用JOIN ON或者JOIN USING。
目标表1 join 目标表2 on (连接条件)
目标表1 join 目标表2 using (连接列集合)
注意:对于使用JOIN USING的标准SQL而言,如果连接列同时又出现在查询列中,则该连接列前不能带上表名或者表名的别名(alias),否则Oracle会报错(ORA-25154)。
特殊的JOIN USING,我们称之为NATURAL JOIN,使用NATURAL JOIN的表连接的连接列是表连接的两个表所有的同名列。
目标表1 natural join 目标表2
相当于:目标表1 join 目标表2 using (目标表1和目标表2的所有同名列集合)
(2)、外连接
左连接:目标表1 left outer join 目标表2 on (连接条件)
目标表1 left outer join 目标表2 u si n g (连接列集合)
left outer join左边的目标表1作为表连接的驱动表,即表明位置处于left的表就是outer table,驱动表。此时连接结果除了包含目标表1和目标表2中所有满足该连接条件的记录外,还会包含驱动表(目标表1)中所有不满足该连接条件的记录,同时,驱动表中所有不满足该连接条件的纪录所对应的被驱动表(目标表2)中的查询列均会以NULL值来填充。
右连接:目标表1 right outer join 目标表2 on (连接条件)
目标表1 right outer join 目标表2 using (连接列集合)
目录
相关文章
|
5天前
|
SQL 存储 关系型数据库
【MySQL系列笔记】SQL优化
SQL优化是通过调整数据库查询、索引、表结构和配置参数等方式,提高SQL查询性能和效率的过程。它旨在减少查询执行时间、减少系统资源消耗,从而提升数据库系统整体性能。优化方法包括索引优化、查询重写、表分区、适当选择和调整数据库引擎等。
26 3
|
7天前
|
存储 SQL 缓存
30个业务场景的SQL优化
这些优化策略和示例可以帮助改善 `SQL` 查询的性能和效率。在实践中,需要综合考虑数据库设计、`SQL` 编写、服务器配置等多方面因素,选择合适的优化方法,并进行充分的测试和验证。以上 30 个经验是 V 哥在实际经验中总结的内容,当然,业务场景不同,具体的优化策略也会不同,按实际情况处理,这不就是程序员要做的事情么。
|
7天前
|
SQL 存储 算法
clickhouse SQL优化
clickhouse 是 OLAP 数据库,但其具有独特的索引设计,所以如果拿 MySQL 或者其他 RDB 的优化经验来优化 clickhouse 可能得不到很好的效果,所以特此单独整理一篇文档,用于有 SQL 优化需求的同学,本人接触 clickhouse 时间也不长,难免有不足的地方,如果大家发现错误,还请不吝指正。
|
10天前
|
SQL 关系型数据库 MySQL
【MySQL】SQL优化
【MySQL】SQL优化
|
11天前
|
SQL 存储 关系型数据库
MySQL SQL优化
MySQL SQL优化
12 0
|
14天前
|
SQL 分布式计算 资源调度
一文解析 ODPS SQL 任务优化方法原理
本文重点尝试从ODPS SQL的逻辑执行计划和Logview中的执行计划出发,分析日常数据研发过程中各种优化方法背后的原理,覆盖了部分调优方法的分析,从知道怎么优化,到为什么这样优化,以及还能怎样优化。
103478 1
|
17天前
|
存储 Oracle 数据管理
Oracle 12c的自动数据优化(ADO)与热图:数据管理的“瘦身”与“透视”艺术
【4月更文挑战第19天】Oracle 12c的ADO和热图技术革新数据管理。ADO智能清理无用数据,优化存储,提升查询速度,实现数据&quot;瘦身&quot;;热图则以直观的视觉表示展示数据分布和状态,助力识别性能瓶颈,犹如数据的&quot;透视&quot;工具。这两项技术结合,强化数据管理,为企业业务发展保驾护航。
|
17天前
|
SQL Oracle 关系型数据库
Oracle的PL/SQL游标自定义异常:数据探险家的“专属警示灯”
【4月更文挑战第19天】Oracle PL/SQL中的游标自定义异常是处理数据异常的有效工具,犹如数据探险家的警示灯。通过声明异常名(如`LOW_SALARY_EXCEPTION`)并在满足特定条件(如薪资低于阈值)时使用`RAISE`抛出异常,能灵活应对复杂业务规则。示例代码展示了如何在游标操作中定义和捕获自定义异常,提升代码可读性和维护性,确保在面对数据挑战时能及时响应。掌握自定义异常,让数据管理更从容。
|
17天前
|
SQL Oracle 安全
Oracle的PL/SQL游标异常处理:从“惊涛骇浪”到“风平浪静”
【4月更文挑战第19天】Oracle PL/SQL游标异常处理确保了在数据操作中遇到的问题得以优雅解决,如`NO_DATA_FOUND`或`TOO_MANY_ROWS`等异常。通过使用`EXCEPTION`块捕获并处理这些异常,开发者可以防止程序因游标问题而崩溃。例如,当查询无结果时,可以显示定制的错误信息而不是让程序终止。掌握游标异常处理是成为娴熟的Oracle数据管理员的关键,能保证在复杂的数据环境中稳健运行。
|
17天前
|
SQL Oracle 安全
Oracle的PL/SQL异常处理方法:守护数据之旅的“魔法盾”
【4月更文挑战第19天】Oracle PL/SQL的异常处理机制是保障数据安全的关键。通过预定义异常(如`NO_DATA_FOUND`)和自定义异常,开发者能优雅地管理错误。异常在子程序中抛出后会向上传播,直到被捕获,提供了一种集中处理错误的方式。理解和善用异常处理,如同手持“魔法盾”,确保程序在面对如除数为零、违反约束等挑战时,能有效保护数据的完整性和程序的稳定性。

推荐镜像

更多