Oracle語句優化30個規則詳解

1. 選用適合的Oracle優化器

Oracle的優化器共有3種：

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形式的優化器。

在缺省狀況下，ORACLE採用CHOOSE優化器，爲了不那些沒必要要的全表掃描(full table scan) ， 你必須儘可能避免使用CHOOSE優化器，而直接採用基於規則或者基於成本的優化器。

 

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語句是相同的(能夠共享)，而第二組中的兩個語句是不一樣的(即便在運行時，賦於不一樣的綁定變量相同的值)

a.

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

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

 

b.

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

AS

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

AS

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是惟一性索引，可是因爲它所作的是範圍比較， 等級要比非惟一性索引的等式比較低!