基于Oracle的SQL优化--学习（四）

第一章的总结

（1）在使用 RBO 的情况下，我们可以通过调整相关对象在数据字典缓存中的缓存顺序，改变目标 sQL 中所涉及的各个对象在该 SQL 文本中出现的先后顺序，或者等价改写该 SQL 来调整其执行计划。

（2）成本是指 Oracle 根据相关对象的统计信息计算出来的一个值，它实际上代表了 Oracle 根据相关统计信息估算出来的目标 SQL 的对应执行路径的 I / O 、 CPU 和网络资源的消耗量。 

（3）cardinality 和 selectivity 的值会直接影响 cBO 对于相关执行步骤成本值的估算，进而影响 CBO 对于目标 SQL 执行计划的选择。

（4）可传递性的意义在于提供了更多的执行路径（ Access Path ）给 CBO 做选择，增加了走出更高效执行计划的可能性。

（5）优化器的模式对 CBO 计算成本（进而对 CBO 选择执行计划）有着决定性的影响。

（6）不是说全表扫描不好，事实上 Orade 在做全表扫描操作时会使用多块读，这在目标表的数据量不大时执行效率是非常高的，但全表扫描最大的问题就在于走全表扫描的目标 SQL 的执行时间会不稳定、不可控，这个执行时间一定会随着目标表数据量的递增而递增。

（7）通过 B 树索引访问表里行记录的效率并不会随着相关表的数据量的递增而显著降低，即通过走索引访问数据的时间是可控的、基本稳定的，这也是走索引和全表扫描的最大区别。

（8）Oracle 中索引全扫描的执行结果是有序的，并且是按照该索引的索引键位列来排序的，这意味右走索引全扫描能够既达到排序的效果，同时又能避免对该索引的索引键值列的真正排序操作。另外， Oracle 中能做索引全扫描的前提条件是目标索引至少有一个索引键值列的属性是 NOT NULL 。

（9）索引快速全扫描是可以并行执行的，它的执行结果不一定是有序的。

（10）Oracle 中的索引跳跃式扫描仅仅适用于那些目标索引的前导列的 distinct 值数量较少、后续非前导列的可选择性又非常好的情形，因为索引跳跃式扫描的执行效率 · 定会随着目标索引前导列的 distinct 值数量的递增而递减。

（11）关键字“ ( + ) ”出现在哪个表的连接列后面，就表明嘟个表会以 NULL 值来填充那些不满足连接条件并位于该表中的查询列，此时应该以关键字“ ( + ) ”对面的表来作为外连接的驱动表，这里的关键是决定哪个表是驱动表。

（12）通常情况 F下，排序合并连接的执行效率会远不如哈希连接的执行效率高，但排序合并连接的使用范围更广，因为哈希连接只能用干等值连接条件，而排序合并连接还能用于其他连接条件（例如＜、＜＝、 》 、＞二）。

（13）通常情况下，排序合并连接并不适合 OLTP 类型的系统，其本质原因是对于 OLTP 类型的系统而言，排序是非常昂贵的操作，当然，如果能避免排序操作，那么即使是 OLTP 类型的系统，还是可以使用排序合并连接的。

（14）如果驱动表所对应的驱动结果集的记录数较少，同时在被驱动表的连接列上又存在唯一性索引（或者在被驱动表的连接列上存在选择性很好的非唯一性索引），那么此时使用嵌套循环连接的执行效率就会非常高；但如果驱动表所对应的驱动结果集的记录数很大，即便在被驱动表的连接列上存在索引，此时使用嵌套循环连接的执行效率也不会高。

（15）大表也可以作为嵌套循环连接的驱动表，关键看目标 SQL 中指定的谓词条件（如果有的话）能否将驱动结果集的数据最降卜来。

（16）哈希连接只适用于 CBO ，它也只能用于等值连接条件（即使是哈希反连接， Oracle 实际上也是将其转换成了等价的等值连接）

（17）哈希连接很适合于小表和大表之间做表连接且．连接结果集的记录数较大的情形，特别是在小表的连接列的可选择性非常好的情况下，这时候哈希连接的执行时间就可以近似看作是和全表扫描那个大表所耗费的时间相当。

（18）半连接和普通的内连接不同，半连接实际上会去重。