Oracle的执行计划及数据存取方式 (ROWID,扫描方式等)

一．相关的概念

ROWID --   rowid是一个伪列，既然是伪列，那么这个列就不是用户定义，
而是系统己给加上的。对每个表都有一个rowid的伪列，但是表中并不物理
存储ROWID列的值。不过你可以像使用其它列那样使用它，但是不能删除
该列，也不能对该列的值进行修改、插入。一旦一行数据插入数据库，
则rowid在该行的生命周期内是唯一的，即即使该行产生行迁移，行的rowid
也不会改变。

ROWID的格式 -- OOOOOOFFFBBBBBBRRR , OOOOOO表示该行所在的对象号，FFF
表示该行所在的相对文件号，BBBBBB表示该数据行所在的数据块号，RRR表示
该行在数据块中的行号 。ROWID采用64进制来表示，可以是A~Z,a~z,0~9,/,+
这64个字符来表示。 很多针对rowid的操作都可以借助dbms_rowid包来进行。

Recursive SQL概念：有时为了执行用户发出的一个sql语句，Oracle必须执行
一些额外的语句，我们将这些额外的语句称之为'recursive calls'或'recursive
SQL statements'。如当一个DDL语句发出后，ORACLE总是隐含的发出一些recursive
SQL语句，来修改数据字典信息，以便用户可以成功的执行该DDL语句。当需要的数
据字典信息没有在共享内存中时，经常会发生Recursive calls，这些Recursive calls
会将数据字典信息从硬盘读入内存中。用户不必关心这些recursive SQL语句的执行
情况，在需要的时候，ORACLE会自动的在内部执行这些语句。当然DML语句与SELECT都
可能引起recursive SQL。简单的说，我们可以将触发器视为recursive SQL。

Row Source(行源)：用在查询中，由上一操作返回的符合条件的行的集合，即可以是
表的全部行数据的集合；也可以是表的部分行数据的集合；也可以为对上2个row source
进行连接操作(如join连接)后得到的行数据集合。

Predicate(谓词)：一个查询中的WHERE限制条件

Driving Table(驱动表)：该表又称为外层表(OUTER TABLE)。这个概念用于嵌套于HASH
连接中。如果该row source返回较多的行数据，则对所有的后续操作有负面影响。注意
此处虽然翻译为驱动表，但实际上翻译为驱动行源(driving row source)更为确切。一
般说来，是应用查询的限制条件后，返回较少行源的表作为驱动表，所以如果一个大表
在WHERE条件有有限制条件(如等值限制)，则该大表作为驱动表也是合适的，所以并不
是只有较小的表可以作为驱动表，正确说法应该为应用查询的限制条件后，返回较少行
源的表作为驱动表。在执行计划中，应该为靠上的那个row source，后面会给出具体
说明。在我们后面的描述中，一般将该表称为连接操作的row source 1 。 

Probed Table(被探查表)：该表又称为内层表(INNER TABLE)。在我们从驱动表中得
到具体一行的数据后，在该表中寻找符合连接条件的行。所以该表应当为大表(实际
上应该为返回较大row source的表)且相应的列上应该有索引。在我们后面的描述中，
一般将该表称为连接操作的row source 2。

组合索引(concatenated index)：由多个列构成的索引，如create index idx_emp
on emp(col1, col2, ol3, ……)，则我们称idx_emp索引为组合索引。在组合索引
中有一个重要的概念：引导列(leading column)，在上面的例子中，col1列为引导
列。当我们进行查询时可以使用”where col1 = ? ”，也可以使用”where col1 = ?
and col2 = ?”，这样的限制条件都会使用索引，但是”where col2 = ? ”查询就
不会使用该索引。所以限制条件中包含先导列时，该限制条件才会使用该组合索引。

可选择性(selectivity)：比较一下列中唯一键的数量和表中的行数，就可以判断该
列的可选择性。如果该列的”唯一键的数量/表中的行数”的比值越接近1，则该列
的可选择性越高，该列就越适合创建索引，同样索引的可选择性也越高。在可选择
性高的列上进行查询时，返回的数据就较少，比较适合使用索引查询。

二．oracle访问数据的存取方法

1) 全表扫描（Full Table Scans, FTS）

为实现全表扫描，Oracle读取表中所有的行，并检查每一行是否满足语句的WHERE
限制条件,一个多块读操作可以使一次I/O能读取多块数据块(db_block_multiblock_read_count
参数设定)，而不是只读取一个数据块，这极大的减少了I/O总次数，提高了系统的吞
吐量，所以利用多块读的方法可以十分高效地实现全表扫描，而且只有在全表扫描的
情况下才能使用多块读操作。在这种访问模式(FTS)下，每个数据块只被读一次。

使用FTS的前提条件：在较大的表上不建议使用全表扫描，除非取出数据的比较多，
超过总量的5% -- 10%，或你想使用并行查询功能时。

使用全表扫描的例子：

SQL> explain plan for select * from dual;
Query Plan-------------------------------
SELECT STATEMENT[CHOOSE]
Cost=TABLE ACCESS FULL DUAL

 

2) 通过ROWID的表存取（Table Access by ROWID或rowid lookup）

行的ROWID指出了该行所在的数据文件、数据块以及行在该块中的位置，所
以通过ROWID来存取数据可以快速定位到目标数据上，是Oracle存取单行数据
的最快方法。

这种存取方法不会用到多块读操作，一次I/O只能读取一个数据块。我们会
经常在执行计划中看到该存取方法，如通过索引查询数据。

使用ROWID存取的方法：

SQL> explain plan for select * from dept
where rowid = 'AAAAyGAADAAAAATAAF';
Query Plan------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID DEPT [ANALYZED]

 

3）索引扫描（Index Scan或index lookup）

我们先通过index查找到数据对应的rowid值(对于非唯一索引可能返回多个
rowid值)，然后根据rowid直接从表中得到具体的数据(ROWID指出了该行所
在的数据文件、数据块以及行在该块中的位置)，这种查找方式称为索引扫
描或索引查找(index lookup)。一个rowid唯一的表示一行数据，该行对应
的数据块是通过一次I/O得到的，在此情况下该次I/O只会读取一个数据库块。

在索引中，除了存储每个索引的值外，索引还存储具有此值的行对应的ROWID
值。索引扫描可以由2步组成：  
(1) 扫描索引得到对应的rowid值(对索引的一次I/O)。
(2) 通过rowid从表中读出具体的数据(读取数据的一次I/O)。

每步都是单独的一次I/O，但是对于索引，由于经常使用，绝大多数都已经
CACHE到内存中，所以第1步的I/O(这里指针对INDEX的I/O)经常是逻辑I/O，
即数据可以从内存中得到。但是对于第2步来说，如果表比较大，则其数据
不可能全在内存中，所以其I/O很有可能是物理I/O，这是一个机械操作，相
对逻辑I/O来说，是极其费时间的。所以如果大表进行索引扫描，取出的
数据如果大于总量的5% -- 10%，使用索引扫描会效率下降很多。如下列所示：

SQL> explain plan for select empno,
ename from emp where empno=10;
Query Plan-------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1

但是如果查询的数据能全在索引中找到，就可以避免进行第2步操作，避免了
不必要的I/O，此时即使通过索引扫描取出的数据比较多，效率还是很高的
(当然这种情况下比较有用的使用是通过联合索引的第一个引导列查询出其
他非索引引导列)。

SQL> explain plan for select empno from emp where empno=10;
-- 只查询empno列值
Query Plan------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1INDEX UNIQUE SCAN EMP_I1

进一步讲，如果sql语句中对索引列进行排序，因为索引已经预先排序好了，
所以在执行计划中不需要再对索引列进行排序

SQL> explain plan for select empno,
ename from empwhere empno > 7876 order by empno;
Query Plan--------------------------------------
SELECT STATEMENT[CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]

从这个例子中可以看到：因为索引是已经排序了的，所以将按照索引的
顺序查询出符合条件的行，因此避免了进一步排序操作。

根据索引的类型与where限制条件的不同，有4种类型的索引扫描：

索引唯一扫描(index unique scan)
索引范围扫描(index range scan)
索引全扫描(index full scan)
索引快速扫描(index fast full scan)

(1) 索引唯一扫描(index unique scan)

通过唯一索引查找一个数值经常返回单个ROWID。如果存在UNIQUE 或
PRIMARY KEY 约束（它保证了语句只存取单行）的话，Oracle经常实
现唯一性扫描。

使用唯一性约束的例子：

SQL> explain plan for
select empno,ename from emp where empno=10;
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1

(2) 索引范围扫描(index range scan)

使用一个索引存取多行数据，在唯一索引上使用索引范围扫描的典型
情况下是在谓词(where限制条件)中使用了范围操作符(如>、、
>=、<=、between)

使用索引范围扫描的例子：

SQL> explain plan for select empno,
ename from emp where empno > 7876 order by empno;
Query Plan-------------------------------------
SELECT STATEMENT[CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]

在非唯一索引上，谓词col = 5可能返回多行数据，所以在非唯一
索引上都使用索引范围扫描。

使用index rang scan的3种情况：
(a) 在唯一索引列上使用了range操作符(> < <> >= <= between)
(b) 在组合索引上，只使用部分列进行查询，导致查询出多行
(c) 对非唯一索引列上进行的任何查询。

(3) 索引全扫描(index full scan)

与全表扫描对应，也有相应的全索引扫描。而且此时查询出的数据都
必须从索引中可以直接得到。

全索引扫描的例子：

An Index full scan will not perform. single block
i/o's and so it may prove to be inefficient.

e.g.Index BE_IX is a concatenated index on big_emp (empno, ename)

SQL> explain plan for select empno, ename from big_emp order
by empno,ename;
Query Plan--------------------------
SELECT STATEMENT[CHOOSE] Cost=26
INDEX FULL SCAN BE_IX [ANALYZED]

(4) 索引快速扫描(index fast full scan)

扫描索引中的所有的数据块，与 index full scan很类似，但是一个
显著的区别就是它不对查询出的数据进行排序，即数据不是以排序顺序
被返回。在这种存取方法中，可以使用多块读功能，也可以使用并行
读入，以便获得最大吞吐量与缩短执行时间。

索引快速扫描的例子：

BE_IX索引是一个多列索引：

big_emp (empno,ename)
SQL> explain plan for select empno,
ename from big_emp;
Query Plan--------------------------
SELECT STATEMENT[CHOOSE] Cost=1
INDEX FAST FULL SCAN BE_IX [ANALYZED]

只选择多列索引的第2列：

SQL> explain plan for select ename from big_emp;
Query Plan--------------------------------------
SELECT STATEMENT[CHOOSE] Cost=1
INDEX FAST FULL SCAN BE_IX [ANALYZED]

 

--------------------------------------------------------------------------------------------

Index Full Scan (索引全扫描)    --------- 

当进行index full scan的时候，oracle定位到索引的root block，
然后到branch block（假如有的话），再定位到第一个leaf block, 然后
根据leaf block的双向链表顺序读取。它所读取的块都是有顺序的，也是
经过排序的，所以index full scan可以用来避免某些sort操作。查询出的
数据都必须从索引中可以直接得到。   这个full scan的名字有点误导人，
其实并不是所有的index block都被读取的，某些分支块是不会读到的。

1.   查询出来的数据都必须从Index中可以直接得到。  
2.   Index中至少有一个字段是非空 。 
3.   可以消除掉排序操作，因为数据已经被index key 排好序了 。 
4.   它一个一个地读取block,  不能多块读 。也不能并行。

 

Index Fast Full Scan (索引快速全扫描)  -----  
而index fast full scan则不同，它是从段头开始，读取包含位图块，
root block, 所有的branch block, leaf block，读取的顺序完全由物理存
储位置决定，并采取多块读，每次读取db_file_multiblock_read_count个块。
因为能并行或多块读，index fast full scan不能用来消除sort操作。 

1.   这种Index Fast Full Scan 只有在CBO下有效
2.   需要分析Index , 否则优化程序可能不会用它
3.    在Index中取数据，而不是存取table中的数据
4.    Index中至少一个字段是非空
5.    不能消除排序操作， 因为数据没排序
6.    与Index Full Scan不一样，用多块读方式读整个Index 
7.    Index Fast Full Scan 比 正常的Index Full Scan 更快，因为能用多块读方式，且能并行执行
8.     Index Fast Full Scan 并行和表的并行是分开的， 可以通过Parallel 来设置 

 

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

转载于:http://blog.itpub.net/35489/viewspace-671696/