Oracle语句优化30个规则详解

时间 2019-11-16

原文原文链接

1. 选用适合的Oracle优化器数据库

Oracle的优化器共有3种：session

a. RULE (基于规则)函数

b. COST (基于成本)工具

c. CHOOSE (选择性)性能

设置缺省的优化器，能够经过对init.ora文件中OPTIMIZER_MODE参数的各类声明，如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS . 你固然也在SQL句级或是会话(session)级对其进行覆盖。测试

为了使用基于成本的优化器(CBO， Cost-Based Optimizer) ，你必须常常运行analyze 命令，以增长数据库中的对象统计信息(object statistics)的准确性。优化

若是数据库的优化器模式设置为选择性(CHOOSE)，那么实际的优化器模式将和是否运行过analyze命令有关。若是table已经被analyze过，优化器模式将自动成为CBO ，反之，数据库将采用RULE形式的优化器。spa

在缺省状况下，ORACLE采用CHOOSE优化器，为了不那些没必要要的全表扫描(full table scan) ，你必须尽可能避免使用CHOOSE优化器，而直接采用基于规则或者基于成本的优化器。orm

2. 访问Table的方式Oracle采用两种访问表中记录的方式：对象

a. 全表扫描

全表扫描就是顺序地访问表中每条记录。 ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描。

b. 经过ROWID访问表

你能够采用基于ROWID的访问方式状况，提升访问表的效率， ROWID包含了表中记录的物理位置信息……ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系。一般索引提供了快速访问ROWID的方法，所以那些基于索引列的查询就能够获得性能上的提升。

3. 共享SQL语句

为了避免重复解析相同的SQL语句，在第一次解析以后， ORACLE将SQL语句存放在内存中。这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存能够被全部的数据库用户共享。所以，当你执行一个SQL语句(有时被称为一个游标)时，若是它和以前的执行过的语句彻底相同， ORACLE就能很快得到已经被解析的语句以及最好的执行路径。 ORACLE的这个功能大大地提升了SQL的执行性能并节省了内存的使用。

惋惜的是ORACLE只对简单的表提供高速缓冲(cache buffering) ，这个功能并不适用于多表链接查询。

数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就能够保留更多的语句，固然被共享的可能性也就越大了。

当你向ORACLE 提交一个SQL语句，ORACLE会首先在这块内存中查找相同的语句。

这里须要注明的是，ORACLE对二者采起的是一种严格匹配，要达成共享，SQL语句必须彻底相同(包括空格，换行等)。

共享的语句必须知足三个条件：

A. 字符级的比较：

当前被执行的语句和共享池中的语句必须彻底相同。

例如：

SELECT * FROM EMP;

和下列每个都不一样

SELECT * from EMP;

Select * From Emp;

SELECT * FROM EMP;

B. 两个语句所指的对象必须彻底相同：

例如：

用户对象名如何访问

Jack sal_limit private synonym

Work_city public synonym

Plant_detail public synonym

Jill sal_limit private synonym

Work_city public synonym

Plant_detail table owner

考虑一下下列SQL语句可否在这两个用户之间共享。

SQL 可否共享缘由

select max(sal_cap) from sal_limit; 不能每一个用户都有一个private synonym - sal_limit , 它们是不一样的对象

select count(*0 from work_city where sdesc like 'NEW%'; 能两个用户访问相同的对象public synonym - work_city

select a.sdesc,b.location from work_city a , plant_detail b where a.city_id = b.city_id 不能用户jack 经过private synonym访问plant_detail 而jill 是表的全部者,对象不一样.

C. 两个SQL语句中必须使用相同的名字的绑定变量(bind variables)

例如：第一组的两个SQL语句是相同的(能够共享)，而第二组中的两个语句是不一样的(即便在运行时，赋于不一样的绑定变量相同的值)

select pin ， name from people where pin = ：blk1.pin;

select pin ， name from people where pin = ：blk1.ot_ind;

select pin ， name from people where pin = ：blk1.ov_ind;

4. 选择最有效率的表名顺序(只在基于规则的优化器中有效)

ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，所以FROM子句中写在最后的表(基础表 driving table)将被最早处理。在FROM子句中包含多个表的状况下，你必须选择记录条数最少的表做为基础表。当ORACLE处理多个表时，会运用排序及合并的方式链接它们。首先，扫描第一个表(FROM子句中最后的那个表)并对记录进行派序，而后扫描第二个表(FROM子句中最后第二个表)，最后将全部从第二个表中检索出的记录与第一个表中合适记录进行合并。

例如：

表 TAB1 16，384 条记录

表 TAB2 1 条记录

选择TAB2做为基础表 (最好的方法)

select count(*) from tab1，tab2 执行时间0.96秒

选择TAB2做为基础表 (不佳的方法)

select count(*) from tab2，tab1 执行时间26.09秒

若是有3个以上的表链接查询，那就须要选择交叉表(intersection table)做为基础表，交叉表是指那个被其余表所引用的表。

例如： EMP表描述了LOCATION表和CATEGORY表的交集。

SELECT *

FROM LOCATION L ,

CATEGORY C,

EMP E

WHERE E.EMP_NO BETWEEN 1000 AND 2000

AND E.CAT_NO = C.CAT_NO

AND E.LOCN = L.LOCN

将比下列SQL更有效率

SELECT *

FROM EMP E ,

LOCATION L ,

CATEGORY C

WHERE E.CAT_NO = C.CAT_NO

AND E.LOCN = L.LOCN

AND E.EMP_NO BETWEEN 1000 AND 2000

5. WHERE子句中的链接顺序。

ORACLE采用自下而上的顺序解析WHERE子句，根据这个原理，表之间的链接必须写在其余WHERE条件以前，那些能够过滤掉最大数量记录的条件必须写在WHERE子句的末尾。

例如：

（低效，执行时间156.3秒）

SELECT …

FROM EMP E

WHERE SAL > 50000

AND JOB = ‘MANAGER’

AND 25 < (SELECT COUNT(*) FROM EMP

WHERE MGR=E.EMPNO);

(高效,执行时间10.6秒)

SELECT …

FROM EMP E

WHERE 25 < (SELECT COUNT(*) FROM EMP

WHERE MGR=E.EMPNO)

AND SAL > 50000

AND JOB = ‘MANAGER’;

6. SELECT子句中避免使用 ‘ * ’

当你想在SELECT子句中列出全部的COLUMN时，使用动态SQL列引用 ‘*’ 是一个方便的方法。不幸的是，这是一个很是低效的方法。实际上，ORACLE在解析的过程当中，会将‘*’ 依次转换成全部的列名，这个工做是经过查询数据字典完成的，这意味着将耗费更多的时间。

7. 减小访问数据库的次数

当执行每条SQL语句时， ORACLE在内部执行了许多工做：解析SQL语句，估算索引的利用率，绑定变量，读数据块等等。因而可知，减小访问数据库的次数，就能实际上减小ORACLE的工做量。

例如，如下有三种方法能够检索出雇员号等于0342或0291的职员。

方法1 (最低效)

SELECT EMP_NAME , SALARY , GRADE

FROM EMP

WHERE EMP_NO = 342;

SELECT EMP_NAME , SALARY , GRADE

FROM EMP

WHERE EMP_NO = 291;

方法2 (次低效)

DECLARE

CURSOR C1 (E_NO NUMBER) IS

SELECT EMP_NAME,SALARY,GRADE

FROM EMP

WHERE EMP_NO = E_NO;

BEGIN

OPEN C1(342);

FETCH C1 INTO …,..,.. ;

OPEN C1(291);

FETCH C1 INTO …,..,.. ;

CLOSE C1; END;

方法3 (高效)

SELECT A.EMP_NAME , A.SALARY , A.GRADE,

B.EMP_NAME , B.SALARY , B.GRADE

FROM EMP A,EMP B

WHERE A.EMP_NO = 342

AND B.EMP_NO = 291;

注意：

在SQL*Plus ， SQL*Forms和Pro*C中从新设置ARRAYSIZE参数，能够增长每次数据库访问的检索数据量，建议值为200.

8. 使用DECODE函数来减小处理时间

使用DECODE函数能够避免重复扫描相同记录或重复链接相同的表。

例如：

SELECT COUNT(*)，SUM(SAL)

FROM EMP

WHERE DEPT_NO = 0020

AND ENAME LIKE ‘SMITH%’;

SELECT COUNT(*)，SUM(SAL)

FROM EMP

WHERE DEPT_NO = 0030

AND ENAME LIKE ‘SMITH%’;

你能够用DECODE函数高效地获得相同结果

SELECT COUNT(DECODE(DEPT_NO,0020,’X’,NULL)) D0020_COUNT,

COUNT(DECODE(DEPT_NO,0030,’X’,NULL)) D0030_COUNT,

SUM(DECODE(DEPT_NO,0020,SAL,NULL)) D0020_SAL,

SUM(DECODE(DEPT_NO,0030,SAL,NULL)) D0030_SAL

FROM EMP WHERE ENAME LIKE ‘SMITH%’;

相似的，DECODE函数也能够运用于GROUP BY 和ORDER BY子句中。

9. 整合简单，无关联的数据库访问

若是你有几个简单的数据库查询语句，你能够把它们整合到一个查询中(即便它们之间没有关系)

例如：

SELECT NAME

FROM EMP

WHERE EMP_NO = 1234;

SELECT NAME

FROM DPT

WHERE DPT_NO = 10 ;

SELECT NAME

FROM CAT

WHERE CAT_TYPE = ‘RD’;

上面的3个查询能够被合并成一个：

SELECT E.NAME , D.NAME , C.NAME

FROM CAT C , DPT D , EMP E,DUAL X

WHERE NVL(‘X’,X.DUMMY) = NVL(‘X’,E.ROWID(+))

AND NVL(‘X’,X.DUMMY) = NVL(‘X’,D.ROWID(+))

AND NVL(‘X’,X.DUMMY) = NVL(‘X’,C.ROWID(+))

AND E.EMP_NO(+) = 1234

AND D.DEPT_NO(+) = 10

AND C.CAT_TYPE(+) = ‘RD’;

(译者按：虽然采起这种方法，效率获得提升，可是程序的可读性大大下降，因此读者仍是要权衡之间的利弊)

10. 删除重复记录

最高效的删除重复记录方法 ( 由于使用了ROWID)

DELETE FROM EMP E

WHERE E.ROWID > (SELECT MIN(X.ROWID)

FROM EMP X

WHERE X.EMP_NO = E.EMP_NO);

11. 用TRUNCATE替代DELETE

当删除表中的记录时，在一般状况下，回滚段(rollback segments ) 用来存放能够被恢复的信息。若是你没有COMMIT事务，ORACLE会将数据恢复到删除以前的状态(准确地说是恢复到执行删除命令以前的情况)

而当运用TRUNCATE时，回滚段再也不存听任何可被恢复的信息。当命令运行后，数据不能被恢复。所以不多的资源被调用，执行时间也会很短。

(译者按： TRUNCATE只在删除全表适用，TRUNCATE是DDL不是DML)

12. 尽可能多使用COMMIT

只要有可能，在程序中尽可能多使用COMMIT，这样程序的性能获得提升，需求也会由于COMMIT所释放的资源而减小：COMMIT所释放的资源：

a. 回滚段上用于恢复数据的信息。

b. 被程序语句得到的锁

c. redo log buffer 中的空间

d. ORACLE为管理上述3种资源中的内部花费

(译者按：在使用COMMIT时必需要注意到事务的完整性，现实中效率和事务完整性每每是鱼和熊掌不可得兼)

13. 计算记录条数

和通常的观点相反， count(*) 比count(1)稍快，固然若是能够经过索引检索，对索引列的计数仍旧是最快的。例如 COUNT(EMPNO)

(译者按：在CSDN论坛中，曾经对此有过至关热烈的讨论，做者的观点并不十分准确，经过实际的测试，上述三种方法并无显著的性能差异)

14. 用Where子句替换HAVING子句

避免使用HAVING子句， HAVING 只会在检索出全部记录以后才对结果集进行过滤。这个处理须要排序，总计等操做。若是能经过WHERE子句限制记录的数目，那就能减小这方面的开销。

例如：

低效：

SELECT REGION，AVG(LOG_SIZE)

FROM LOCATION

GROUP BY REGION

HAVING REGION REGION != ‘SYDNEY’

AND REGION != ‘PERTH’

高效：

SELECT REGION，AVG(LOG_SIZE)

FROM LOCATION

WHERE REGION REGION != ‘SYDNEY’

AND REGION != ‘PERTH’

GROUP BY REGION

(译者按： HAVING 中的条件通常用于对一些集合函数的比较，如COUNT() 等等。除此而外，通常的条件应该写在WHERE子句中)

15. 减小对表的查询

在含有子查询的SQL语句中，要特别注意减小对表的查询。

例如：

低效

SELECT TAB_NAME

FROM TABLES

WHERE TAB_NAME = ( SELECT TAB_NAME

FROM TAB_COLUMNS

WHERE VERSION = 604)

AND DB_VER= ( SELECT DB_VER

FROM TAB_COLUMNS

WHERE VERSION = 604)

高效

SELECT TAB_NAME

FROM TABLES

WHERE (TAB_NAME,DB_VER)

= ( SELECT TAB_NAME,DB_VER)

FROM TAB_COLUMNS

WHERE VERSION = 604)

Update 多个Column 例子：

低效：

UPDATE EMP

SET EMP_CAT = (SELECT MAX(CATEGORY) FROM EMP_CATEGORIES),

SAL_RANGE = (SELECT MAX(SAL_RANGE) FROM EMP_CATEGORIES)

WHERE EMP_DEPT = 0020;

高效：

UPDATE EMP

SET (EMP_CAT, SAL_RANGE)

= (SELECT MAX(CATEGORY) , MAX(SAL_RANGE)

FROM EMP_CATEGORIES)

WHERE EMP_DEPT = 0020;

16. 经过内部函数提升SQL效率。

SELECT H.EMPNO,E.ENAME,H.HIST_TYPE,T.TYPE_DESC,COUNT(*)

FROM HISTORY_TYPE T,EMP E,EMP_HISTORY H

WHERE H.EMPNO = E.EMPNO

AND H.HIST_TYPE = T.HIST_TYPE

GROUP BY H.EMPNO,E.ENAME,H.HIST_TYPE,T.TYPE_DESC;

经过调用下面的函数能够提升效率。

FUNCTION LOOKUP_HIST_TYPE(TYP IN NUMBER) RETURN VARCHAR2

TDESC VARCHAR2(30);

CURSOR C1 IS

SELECT TYPE_DESC

FROM HISTORY_TYPE

WHERE HIST_TYPE = TYP;

BEGIN

OPEN C1;

FETCH C1 INTO TDESC;

CLOSE C1;

RETURN (NVL(TDESC,’?’));

END;

FUNCTION LOOKUP_EMP(EMP IN NUMBER) RETURN VARCHAR2

ENAME VARCHAR2(30);

CURSOR C1 IS

SELECT ENAME

FROM EMP

WHERE EMPNO=EMP;

BEGIN

OPEN C1;

FETCH C1 INTO ENAME;

CLOSE C1;

RETURN (NVL(ENAME,’?’));

END;

SELECT H.EMPNO,LOOKUP_EMP(H.EMPNO),

H.HIST_TYPE,LOOKUP_HIST_TYPE(H.HIST_TYPE),COUNT(*)

FROM EMP_HISTORY H

GROUP BY H.EMPNO , H.HIST_TYPE;

(译者按：常常在论坛中看到如 ‘能不能用一个SQL写出…。’ 的贴子，却不知复杂的SQL每每牺牲了执行效率。可以掌握上面的运用函数解决问题的方法在实际工做中是很是有意义的)

17. 使用表的别名(Alias)

当在SQL语句中链接多个表时，请使用表的别名并把别名前缀于每一个Column上。这样一来，就能够减小解析的时间并减小那些由Column歧义引发的语法错误。

(译者注： Column歧义指的是因为SQL中不一样的表具备相同的Column名，当SQL语句中出现这个Column时，SQL解析器没法判断这个Column的归属)

18. 用EXISTS替代IN

在许多基于基础表的查询中，为了知足一个条件，每每须要对另外一个表进行联接。在这种状况下，使用EXISTS(或NOT EXISTS)一般将提升查询的效率。

低效：

SELECT *

FROM EMP (基础表)

WHERE EMPNO > 0

AND DEPTNO IN (SELECT DEPTNO

FROM DEPT

WHERE LOC = ‘MELB’)

高效：

SELECT *

FROM EMP (基础表)

WHERE EMPNO > 0

AND EXISTS (SELECT ‘X’

FROM DEPT

WHERE DEPT.DEPTNO = EMP.DEPTNO

AND LOC = ‘MELB’)

(译者按：相对来讲，用NOT EXISTS替换NOT IN 将更显著地提升效率，下一节中将指出)

19. 用NOT EXISTS替代NOT IN

在子查询中，NOT IN子句将执行一个内部的排序和合并。不管在哪一种状况下，NOT IN都是最低效的 (由于它对子查询中的表执行了一个全表遍历)。为了不使用NOT IN ，咱们能够把它改写成外链接(Outer Joins)或NOT EXISTS.

例如：

SELECT …

FROM EMP

WHERE DEPT_NO NOT IN (SELECT DEPT_NO

FROM DEPT

WHERE DEPT_CAT=’A’);

为了提升效率。改写为：

(方法一：高效)

SELECT ….

FROM EMP A,DEPT B

WHERE A.DEPT_NO = B.DEPT(+)

AND B.DEPT_NO IS NULL

AND B.DEPT_CAT(+) = ‘A’

(方法二：最高效)

SELECT ….

FROM EMP E

WHERE NOT EXISTS (SELECT ‘X’

FROM DEPT D

WHERE D.DEPT_NO = E.DEPT_NO

AND DEPT_CAT = ‘A’);

20. 用表链接替换EXISTS

一般来讲，采用表链接的方式比EXISTS更有效率

SELECT ENAME

FROM EMP E

WHERE EXISTS (SELECT ‘X’

FROM DEPT

WHERE DEPT_NO = E.DEPT_NO

AND DEPT_CAT = ‘A’);

(更高效)

SELECT ENAME

FROM DEPT D,EMP E

WHERE E.DEPT_NO = D.DEPT_NO

AND DEPT_CAT = ‘A’ ;

(译者按：在RBO的状况下，前者的执行路径包括FILTER，后者使用NESTED LOOP)

21. 用EXISTS替换DISTINCT

当提交一个包含一对多表信息(好比部门表和雇员表)的查询时，避免在SELECT子句中使用DISTINCT. 通常能够考虑用EXIST替换

例如：

低效：

SELECT DISTINCT DEPT_NO,DEPT_NAME

FROM DEPT D,EMP E

WHERE D.DEPT_NO = E.DEPT_NO

高效：

SELECT DEPT_NO,DEPT_NAME

FROM DEPT D

WHERE EXISTS ( SELECT ‘X’

FROM EMP E

WHERE E.DEPT_NO = D.DEPT_NO);

EXISTS 使查询更为迅速，由于RDBMS核心模块将在子查询的条件一旦知足后，马上返回结果。

22. 识别‘低效执行’的SQL语句

用下列SQL工具找出低效SQL：

SELECT EXECUTIONS , DISK_READS, BUFFER_GETS,

ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio,

ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run,

SQL_TEXT

FROM V$SQLAREA

WHERE EXECUTIONS>0

AND BUFFER_GETS > 0

AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8

ORDER BY 4 DESC;

(译者按：虽然目前各类关于SQL优化的图形化工具层出不穷，可是写出本身的SQL工具来解决问题始终是一个最好的方法)

23. 使用TKPROF 工具来查询SQL性能状态

SQL trace 工具收集正在执行的SQL的性能状态数据并记录到一个跟踪文件中。这个跟踪文件提供了许多有用的信息，例如解析次数。执行次数，CPU使用时间等。这些数据将能够用来优化你的系统。

设置SQL TRACE在会话级别：

有效

ALTER SESSION SET SQL_TRACE TRUE

设置SQL TRACE 在整个数据库有效仿，你必须将SQL_TRACE参数在init.ora中设为TRUE， USER_DUMP_DEST参数说明了生成跟踪文件的目录

(译者按：这一节中，做者并无提到TKPROF的用法，对SQL TRACE的用法也不够准确，设置SQL TRACE首先要在init.ora中设定TIMED_STATISTICS，这样才能获得那些重要的时间状态。生成的trace文件是不可读的，因此要用TKPROF工具对其进行转换，TKPROF有许多执行参数。你们能够参考ORACLE手册来了解具体的配置。 )

24. 用EXPLAIN PLAN 分析SQL语句

EXPLAIN PLAN 是一个很好的分析SQL语句的工具，它甚至能够在不执行SQL的状况下分析语句。经过分析，咱们就能够知道ORACLE是怎么样链接表，使用什么方式扫描表(索引扫描或全表扫描)以及使用到的索引名称。

你须要按照从里到外，从上到下的次序解读分析的结果。 EXPLAIN PLAN分析的结果是用缩进的格式排列的，最内部的操做将被最早解读，若是两个操做处于同一层中，带有最小操做号的将被首先执行。

NESTED LOOP是少数不按照上述规则处理的操做，正确的执行路径是检查对NESTED LOOP提供数据的操做，其中操做号最小的将被最早处理。

译者按：经过实践，感到仍是用SQLPLUS中的SET TRACE 功能比较方便。

举例：

SQL> list

1 SELECT *

2 FROM dept, emp

3* WHERE emp.deptno = dept.deptno

SQL> set autotrace traceonly /*traceonly 能够不显示执行结果*/

SQL> /

14 rows selected.

Execution Plan

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

0 SELECT STATEMENT ptimizer=CHOOSE

1 0 NESTED LOOPS

2 1 TABLE ACCESS (FULL) OF 'EMP'

3 1 TABLE ACCESS (BY INDEX ROWID) OF 'DEPT'

4 3 INDEX (UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)

Statistics

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

0 recursive calls

2 db block gets

30 consistent gets

0 physical reads

0 redo size

2598 bytes sent via SQL*Net to client

503 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

14 rows processed

经过以上分析，能够得出实际的执行步骤是：

1. TABLE ACCESS (FULL) OF 'EMP'

2. INDEX (UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)

3. TABLE ACCESS (BY INDEX ROWID) OF 'DEPT'

4. NESTED LOOPS (JOINING 1 AND 3)

注：目前许多第三方的工具如TOAD和ORACLE自己提供的工具如OMS的SQL Analyze都提供了极其方便的EXPLAIN PLAN工具。也许喜欢图形化界面的朋友们能够选用它们。

25. 用索引提升效率

索引是表的一个概念部分，用来提升检索数据的效率。实际上，ORACLE使用了一个复杂的自平衡B-tree结构。一般，经过索引查询数据比全表扫描要快。当ORACLE找出执行查询和Update语句的最佳路径时， ORACLE优化器将使用索引。一样在联结多个表时使用索引也能够提升效率。另外一个使用索引的好处是，它提供了主键(primary key)的惟一性验证。

除了那些LONG或LONG RAW数据类型，你能够索引几乎全部的列。一般，在大型表中使用索引特别有效。固然，你也会发现，在扫描小表时，使用索引一样能提升效率。

虽然使用索引能获得查询效率的提升，可是咱们也必须注意到它的代价。索引须要空间来存储，也须要按期维护，每当有记录在表中增减或索引列被修改时，索引自己也会被修改。这意味着每条记录的INSERT ， DELETE ， UPDATE将为此多付出4 ， 5 次的磁盘I/O . 由于索引须要额外的存储空间和处理，那些没必要要的索引反而会使查询反应时间变慢。

译者按：按期的重构索引是有必要的。

ALTER INDEXREBUILD

26. 索引的操做

ORACLE对索引有两种访问模式。

索引惟一扫描 ( INDEX UNIQUE SCAN)

大多数状况下，优化器经过WHERE子句访问INDEX.

例如：

表LODGING有两个索引：创建在LODGING列上的惟一性索引LODGING_PK和创建在MANAGER列上的非惟一性索引LODGING$MANAGER.

SELECT *

FROM LODGING

WHERE LODGING = ‘ROSE HILL’;

在内部，上述SQL将被分红两步执行，首先， LODGING_PK 索引将经过索引惟一扫描的方式被访问，得到相对应的ROWID，经过ROWID访问表的方式执行下一步检索。

若是被检索返回的列包括在INDEX列中，ORACLE将不执行第二步的处理(经过ROWID访问表)。由于检索数据保存在索引中，单单访问索引就能够彻底知足查询结果。

下面SQL只须要INDEX UNIQUE SCAN 操做。

SELECT LODGING

FROM LODGING

WHERE LODGING = ‘ROSE HILL’;

索引范围查询(INDEX RANGE SCAN)

适用于两种状况：

1. 基于一个范围的检索

2. 基于非惟一性索引的检索

例1：

SELECT LODGING FROM LODGING WHERE LODGING LIKE ‘M%’;

WHERE子句条件包括一系列值， ORACLE将经过索引范围查询的方式查询LODGING_PK . 因为索引范围查询将返回一组值，它的效率就要比索引惟一扫描低一些。

例2：

SELECT LODGING

FROM LODGING

WHERE MANAGER = ‘BILL GATES’;

这个SQL的执行分两步， LODGING$MANAGER的索引范围查询(获得全部符合条件记录的ROWID)和下一步同过ROWID访问表获得LODGING列的值。因为LODGING$MANAGER是一个非惟一性的索引，数据库不能对它执行索引惟一扫描。

因为SQL返回LODGING列，而它并不存在于LODGING$MANAGER索引中，因此在索引范围查询后会执行一个经过ROWID访问表的操做。

WHERE子句中，若是索引列所对应的值的第一个字符由通配符(WILDCARD)开始，索引将不被采用。在这种状况下，ORACLE将使用全表扫描。

SELECT LODGING

FROM LODGING

WHERE MANAGER LIKE ‘%HANMAN’;

27. 基础表的选择

基础表(Driving Table)是指被最早访问的表(一般以全表扫描的方式被访问)。根据优化器的不一样， SQL语句中基础表的选择是不同的。

若是你使用的是CBO (COST BASED OPTIMIZER)，优化器会检查SQL语句中的每一个表的物理大小，索引的状态，而后选用花费最低的执行路径。

若是你用RBO (RULE BASED OPTIMIZER) ，而且全部的链接条件都有索引对应，在这种状况下，基础表就是FROM 子句中列在最后的那个表。blog

举例：

SELECT A.NAME ， B.MANAGER

FROM WORKER A，

LODGING B

WHERE A.LODGING = B.LODING;

因为LODGING表的LODING列上有一个索引，并且WORKER表中没有相比较的索引， WORKER表将被做为查询中的基础表。

28. 多个平等的索引

当SQL语句的执行路径可使用分布在多个表上的多个索引时， ORACLE会同时使用多个索引并在运行时对它们的记录进行合并，检索出仅对所有索引有效的记录。

在ORACLE选择执行路径时，惟一性索引的等级高于非惟一性索引。然而这个规则只有当WHERE子句中索引列和常量比较才有效。若是索引列和其余表的索引类相比较。这种子句在优化器中的等级是很是低的。

若是不一样表中两个想同等级的索引将被引用， FROM子句中表的顺序将决定哪一个会被率先使用。 FROM子句中最后的表的索引将有最高的优先级。

若是相同表中两个想同等级的索引将被引用， WHERE子句中最早被引用的索引将有最高的优先级。

举例：

DEPTNO上有一个非惟一性索引，EMP_CAT也有一个非惟一性索引。

SELECT ENAME，

FROM EMP

WHERE DEPT_NO = 20

AND EMP_CAT = ‘A’;

这里，DEPTNO索引将被最早检索，而后同EMP_CAT索引检索出的记录进行合并。执行路径以下：

TABLE ACCESS BY ROWID ON EMP

AND-EQUAL

INDEX RANGE SCAN ON DEPT_IDX

INDEX RANGE SCAN ON CAT_IDX

29. 等式比较和范围比较

当WHERE子句中有索引列， ORACLE不能合并它们，ORACLE将用范围比较。

举例：

DEPTNO上有一个非惟一性索引，EMP_CAT也有一个非惟一性索引：

SELECT ENAME

FROM EMP

WHERE DEPTNO > 20

AND EMP_CAT = ‘A’;

这里只有EMP_CAT索引被用到，而后全部的记录将逐条与DEPTNO条件进行比较。执行路径以下：

TABLE ACCESS BY ROWID ON EMP

INDEX RANGE SCAN ON CAT_IDX

30. 不明确的索引等级

当ORACLE没法判断索引的等级高低差异，优化器将只使用一个索引，它就是在WHERE子句中被列在最前面的。

举例：

DEPTNO上有一个非惟一性索引，EMP_CAT也有一个非惟一性索引。

SELECT ENAME

FROM EMP

WHERE DEPTNO > 20

AND EMP_CAT > ‘A’;

这里， ORACLE只用到了DEPT_NO索引。执行路径以下：

TABLE ACCESS BY ROWID ON EMP

INDEX RANGE SCAN ON DEPT_IDX

译者按：咱们来试一下如下这种状况：

SQL> select index_name， uniqueness from user_indexes where table_name = 'EMP';

INDEX_NAME UNIQUENES

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

EMPNO UNIQUE

EMPTYPE NONUNIQUE

SQL> select * from emp where empno >= 2 and emp_type = 'A' ;

no rows selected

Execution Plan

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

0 SELECT STATEMENT ptimizer=CHOOSE

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'

2 1 INDEX (RANGE SCAN) OF 'EMPTYPE' (NON-UNIQUE)

虽然EMPNO是惟一性索引，可是因为它所作的是范围比较，等级要比非惟一性索引的等式比较低!