本文介绍了Oracle数据库里常见的执行计划,使用的Oracle数据库版本为11.2.0.1。
1、与表访问相关的执行计划
Oracle数据库里与表访问有关的两种方法:全表扫描和ROWID扫描。反映在执行计划上,与全表扫描对应的执行计划中的关键字是“TABLE ACCESS FULL”,与ROWID扫描对应的执行计划中关键字是“TABLE ACCESS BY USER ROWID”或“TABLE ACCESS BY INDEX ROWID”。
从实验中可以看出,第一个SQL执行计划走的是对表EMP的全表扫描,对应的关键字就是“TABLE ACCESS FULL”;第二个SQL的执行计划走的是对表EMP的ROWID扫描,对应的关键字是“TABLE ACCESS BY USER ROWID”;第三个SQL的执行计划走的是对表EMP的ROWID扫描,对应的关键字是“TABLE ACCESS BY INDEX ROWID”。注意如果ROWID来源于用户手工指定则对应的是“TABLE ACCESS BY USER ROWID”;如果ROWID是来源于索引,则对应的是“TABLE ACCESS BY INDEX ROWID”。
2与B*Tree索引相关的执行计划
Oracle数据库里常见的与B*Tree索引访问相关的方法,包括索引唯一扫描、索引范围扫描、索引全扫描、索引快速全扫描和索引跳跃式扫描,反映在执行计划上分别对应INDEX UNIQUE SCAN、INDEX RANGE SCAN、INDEX FULL SCAN、INDEX FAST FULL SCAN和INDEX SKIP SCAN。
用实验查看相关执行计划
第一个SQL的执行计划走的是对索引IDX_UNI_EMP的索引唯一扫描,关键字是“INDEX UNIQUE SCAN”。
现在SQL的执行计划是对索引IDX_EMP_1的索引范围扫描,关键字是“INDEX RANGE SCAN”。
明明可以扫描索引IDX_EMP_1得到结果,却选择了全表扫描,就算使用Hint强制让Oracle扫描索引IDX_EMP_1,结果却是Hint失效了。
出现这个现象的原因是Oracle无论如何总会保证目标SQL结果的正确性,可能会得到错误结果的执行路径Oracle是不会考虑的。对于索引IDX_EMP_1而言,它是一个单键值的B*Tree索引,所以NULL值不会存储在其中,那么一量EMPLOYEE_ID出现了NULL值(虽然这里实际上并没有NULL值),则扫描索引的结果就是漏掉那些EMPLOYEE_ID为NULL值的记录,这也就意味着如果Oracle在执行上述SQL时选择了扫描IDX_EMP_1,那么执行结果就有可能是不准的。在这种情况下,Oracle当然不会考虑扫描索引,即使我们使用了Hint。
如果想让Oracle在执行上述SQL时扫描索引IDX_EMP_1,则必须将列EMPLOYEE_ID的属性修改为NOT NULL。这就相当于告诉Oracle,这里列EMPLOYEE_ID上不会有NULL值,你就放心地扫描索引IDX_EMP_1吧。
从上面的输出可以看出,现在SQL的执行计划走的是对索引IDX_EMP_1的索引快速全扫描,对应的是“INDEX FAST FULL SCAN”。
现在加上强制走索引IDX_EMP_1的Hint,再次执行该SQL
可以看到现在SQL的执行计划走的是对索引IDX_EMP_1的索引快速全扫描INDEX FULL SCAN(如果是在11.2.0.4版本上执行上以SQL可以以看到还是INDEX FAST FULL SCAN)
从上面输出可以看出,SQL的执行计划走的是对索引IDX_EMP_2的索引跳跃式扫描,对应“INDEXSKIP SCAN”。
3、与表连接相关的执行计划
Oracle数据库里常见的与表连接相关的一些方法:排序合并连接、嵌套循环连接、哈希连接等以及反连接和半连接
从上面的输出可以看出,SQL的执行计划走的是对表T1和T2的哈希连接,连接条件是t1.col2=t2.col2,对应的关键字是“HASH JOIN”。
使用强制走排序合并连接的Hint后再次执行SQL
从上面的输出可以看出现在SQL的执行计划走的是对表T1和T2的排序合并连接,对应的关键字是“MERGEJOIN”和“SORT JOIN”。
接着使用强制走嵌套循环连接的Hint后再次执行SQL
从上面的输出可以看出现在SQL的执行计划走的是对表T1和T2的嵌套循环连接,对应的关键字是“NESTEDLOOPS”
嵌套循环连接的驱动表是可以变的,我们使用Hint将上述SQL的驱动表改为T1再将执行SQL
从结果中可以看到,嵌套循环连接的驱动表确实已经变为T1
再看反连接的例子。首先将表T1和T2的连接列col2改为NOT NULL,以便能走出我们想要的反连接的执行计划
从输出内容上可以看出,SQL的执行计划走的是对表T1和T2的哈希反连接,反连接在执行计划中对应的关键字是“ANTI”,哈希反连接对应的就是“HASH JOIN ANTI”。
反连接的具体连接方法是可变的,这里使用Hint将SQL的反连接改为排序合并反连接
从输出内容可以看出,SQL的执行计划走的是对表T1和T2的排序合并反连接,对应的关键字是“MERGE JOIN ANTI”。
再使用Hint将SQL的反连接方法改为嵌套循环反连接
再看半连接的例子。
从输出可以看出,SQL的执行计划走的是对表T1和T2的哈希半连接,半连接在执行计划中对应的关键字是“SEMI”,哈希半连接在执行计划中对应的关键字是“HASH JOIN SEMI”。
半连接的具体连接方法是可变的,使用Hint将SQL的半连接方法改为排序合并半连接:
从输出内容可以看出,SQL的执行计划走的是对表T1和T2的排序合并半连接,对应的关键字是“MERGE JOIN SEMI”。
再使用Hint把SQL的半连接方法改为嵌套循环半连接:
从输出内容可以看出,SQL的执行计划走的是对表T1和T2的嵌套循环半连接,对应的关键字是“NESTED LOOPS SEMI”
4、关于位图索引相关的执行计划
Oracle数据库里常见的与位图索引访问相关的方法包括如下这些类型:位图索引单键值扫描、位图索引范围扫描、位图索引全扫描、位图索引快速全扫描、位图按位与、位图按位或、位图按位减等。
Oracle在使用完位图索引后通常会将最后的位图运算结果转化为ROWID,这一步转换过程对应的执行计划中的“BITMAP CONVERSION TO ROWIDS”。
从上面的输出内容可以看出,SQL的执行计划走的是对位图索引IDX_B_REGION的位图索引单键值扫描,对就的关键字是“BITMAP INDEX SINGLE VALUE”。
把SQL改写为范围查询后再次执行
从输出内容可以看出SQL走的执行计划是对位图索引IDX_B_REGION的位图索引范围扫描,对应的关键字是“BITMAP INDEX RANGE SCAN”。
去掉where条件,并且只查询位图索引IDX_B_REGION的索引键值列:
从输出可以看出SQL走的执行计划是对位图索引IDX_B_REGION的位图索引快速全扫描,对应的关键字是“BIT INDEX FAST FULL SCAN”。
执行如下SQL:
从输出内容可以看出SQL走的执行计划中,用到了位图按位与操作,对应的关键字是“BITMAP AND”和位图按位或操作,对应的关键字是“BITMAP OR”。
再构造位图按位减的执行计划,SQL如下:
从输出的执行计划中,位图按位减的执行计划对应的关键字是“BITMAP MINUX”。