Oracle SQL語句性能優化方法大全

下面列舉一些工做中經常會碰到的Oracle的SQL語句優化方法：

一、SQL語句儘可能用大寫的；

 由於oracle老是先解析SQL語句，把小寫的字母轉換成大寫的再執行。

 

二、選擇最有效率的表名順序(只在基於規則的優化器中有效)：

ORACLE的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表(基礎表 driving table)將被最早處理，在FROM子句中包含多個表的狀況下,你必須選擇記錄條數最少的表做爲基礎表。若是有3個以上的錶鏈接查詢, 那就須要選擇交叉表(intersection table)做爲基礎表, 交叉表是指那個被其餘表所引用的表.

 

三、WHERE子句中的鏈接順序： 

 ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的鏈接必須寫在其餘

WHERE條件以前, 那些能夠過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾

 

四、使用表的別名： 

 當在SQL語句中鏈接多個表時, 儘可能使用表的別名並把別名前綴於每一個列上。這樣一來,

就能夠減小解析的時間並減小那些由列歧義引發的語法錯誤。

 

五、SELECT子句中避免使用 ‘ * ‘：

ORACLE在解析的過程當中, 會將'*' 依次轉換成全部的列名, 這個工做是經過查詢數據字典完成的, 這意味着將耗費更多的時間

 

六、使用DECODE函數來減小處理時間：

使用DECODE函數能夠避免重複掃描相同記錄或重複鏈接相同的表.

 

七、整合簡單無關聯的數據庫訪問

若是有幾個簡單的數據庫查詢語句，你能夠把它們整合到一個查詢中（即便它們之間沒有關係），以減小多於的數據庫IO開銷。

雖然採起這種方法，效率獲得提升，可是程序的可讀性大大下降，因此仍是要權衡之間的利弊。

 

八、使用where而非having

where語句是在group by 語句以前篩選出記錄，而having是在各類記錄都篩選以後再進行過濾，也就是說having子句是在數據庫中提取數據以後再篩選。所以儘可能在篩選以前將數據使用where子句進行過濾，所以執行的順序應該以下

1使用where子句查找符合條件的數據

2使用group by子句對數據進行分組

3在group by分組的基礎上運行聚合函數計算每一組的值

 

九、用(UNION)UNION ALL替換OR (適用於索引列) 
一般狀況下, 用UNION替換WHERE子句中的OR將會起到較好的效果. 對索引列使用OR將形成全表掃描. 
注意, 以上規則只針對多個索引列有效. 若是有column沒有被索引, 查詢效率可能會由於你沒有選擇OR

而下降. 在下面的例子中, LOC_ID 和REGION上都建有索引. 
若是你堅持要用OR, 那就須要返回記錄最少的索引列寫在最前面. 

代碼以下:
高效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 UNION ALL 
SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE REGION = 「MELBOURNE」 
低效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 OR REGION = 
「MELBOURNE」 

 

十、用UNION-ALL 替換UNION ( 若是有可能的話)： 
當SQL語句須要UNION兩個查詢結果集合時,這兩個結果集合會以UNION-ALL的方式被合併, 而後在輸出最
終結果前進行排序. 若是用UNION ALL替代UNION, 這樣排序就不是必要了. 效率就會所以獲得提升. 需
要注意的是，UNION ALL 將重複輸出兩個結果集合中相同記錄. 所以各位仍是要從業務需求分析使用
UNION ALL的可行性. UNION 將對結果集合排序,這個操做會使用到SORT_AREA_SIZE這塊內存. 對於這塊
內存的優化也是至關重要的. 

 

UNION 和 UNION ALL 雖然都是將兩個 SQL 語句的結果合併起來，但也有細微的差異：

UNION 只會獲得不一樣的資料值，相似 DISTINCT。

UNION ALL 會將每一筆符合條件的資料都列出來，不管資料值有無重複。

 

十一、Order By語句加在索引列，最好是主鍵PK上。 

代碼以下:
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE（低效） 
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_CODE （高效）

 

十二、避免使用耗費資源的操做: 
帶有DISTINCT,UNION,MINUS,INTERSECT的SQL語句會啓動SQL引擎 執行耗費資源的排序(SORT)功能. 
DISTINCT須要一次排序操做, 而其餘的至少須要執行兩次排序. 一般, 帶有UNION, MINUS , INTERSECT
的SQL語句均可以用其餘方式重寫. 若是你的數據庫的SORT_AREA_SIZE調配得好, 使用UNION , MINUS, 
INTERSECT也是能夠考慮的, 畢竟它們的可讀性很強 

 

1三、一般來講，若是語句可以避免子查詢的 使用，就儘可能不用子查詢。由於子查詢的開銷是至關昂貴的

 

1四、用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’)

 

15.用NOT EXISTS替代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 E
WHERE NOT EXISTS （SELECT ‘X’
FROM DEPT D
WHERE D.DEPT_NO = E.DEPT_NO
AND DEPT_CAT = ‘A’）

 

16. 用錶鏈接替換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’

 

17.用EXISTS替換DISTINCT 

當提交一個包含對多表信息（好比部門表和僱員表）的查詢時，避免在SELECT子句中使用DISTINCT。 通常能夠考慮用EXIST替換。

EXISTS 使查詢更爲迅速，由於RDBMS核心模塊將在子查詢的條件一旦知足後，馬上返回結果。

低效：

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;

 

18.用索引提升效率：

（1）特色

優勢： 提升效率 主鍵的惟一性驗證

代價： 須要空間存儲 按期維護

重構索引： 

ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>；

 

（2）Oracle對索引有兩種訪問模式

索引惟一掃描 (Index Unique Scan)
索引範圍掃描 (index range scan)

 

（3）基礎表的選擇

基礎表(Driving Table)是指被最早訪問的表(一般以全表掃描的方式被訪問)。 根據優化器的不一樣，SQL語句中基礎表的選擇是不同的。
若是你使用的是CBO (COST BASED OPTIMIZER)，優化器會檢查SQL語句中的每一個表的物理大小，索引的狀態，而後選用花費最低的執行路徑。

（oracle 10g 及之後）
若是你用RBO (RULE BASED OPTIMIZER)， 而且全部的鏈接條件都有索引對應，在這種狀況下，基礎表就是FROM 子句中列在最後的那個表。

（oracle 10g之前）

 

（4）多個平等的索引

當SQL語句的執行路徑可使用分佈在多個表上的多個索引時，ORACLE會同時使用多個索引並在運行時對它們的記錄進行合併，檢索出僅對所有索引有效的記錄。
在ORACLE選擇執行路徑時，惟一性索引的等級高於非惟一性索引。然而這個規則只有當WHERE子句中索引列和常量比較纔有效。若是索引列和其餘表的索引類相比較。這種子句在優化器中的等級是很是低的。
若是不一樣表中兩個相同等級的索引將被引用，FROM子句中表的順序將決定哪一個會被率先使用。 FROM子句中最後的表的索引將有最高的優先級。
若是相同表中兩個相同等級的索引將被引用，WHERE子句中最早被引用的索引將有最高的優先級。

 優先級要看CBO的要結婚表的數據來看。

（5）等式比較優先於範圍比較

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

即便是惟一性索引，若是作範圍比較，其優先級也低於非惟一性索引的等式比較。

 

（6）相同的索引列不能互相比較，這將會啓用全表掃描。

不使用索引：

SELECT ACCOUNT_NAME, AMOUNT
FROM TRANSACTION
WHERE ACCOUNT_NAME = NVL(:ACC_NAME, ACCOUNT_NAME)
使用索引：

SELECT ACCOUNT_NAME，AMOUNT
from transaction
WHERE ACCOUNT_NAME LIKE NVL(:ACC_NAME, ’%’)

 

19.在java代碼中儘可能少用鏈接符「＋」鏈接字符串！

 

20.避免在索引列上使用NOT、<>、!= 一般，　

咱們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響. 當ORACLE」遇到」NOT,他就會中止使用索引轉而執行全表掃描.

對索引列的使用最好就是 where 索引列 = 條件
!=將不使用索引,記住, 索引只能告訴你什麼存在於表中, 而不能告訴你什麼不存在於表中.。

 

21。避免在索引列上使用計算．

WHERE子句中，若是索引列是函數的一部分．優化器將不使用索引而使用全表掃描．
舉例:

低效：
SELECT … FROM DEPT WHERE SAL * 12 > 25000;

高效:
SELECT … FROM DEPT WHERE SAL > 25000/12;

 

22. 用>=替代>

高效:
SELECT * FROM EMP WHERE DEPTNO >=4

低效:
SELECT * FROM EMP WHERE DEPTNO >3
二者的區別在於, 前者DBMS將直接跳到第一個DEPT等於4的記錄然後者將首先定位到DEPTNO=3的記錄而且向前掃描到第一個DEPT大於3的記錄.

 

23識別'低效執行'的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

--and PARSING_SCHEMA_NAME = 'YYII_S6MISM'
ORDER BY 4 DESC;

 

24.避免在索引列上使用IS NULL和IS NOT NULL

避免在索引中使用任何能夠爲空的列，ORACLE將沒法使用該索引．對於單列索引，若是列包含空值，索引中將不存在此記錄. 對於複合索引，若是每一個列都爲空，索引中一樣不存在此記錄.　若是至少有一個列不爲空，則記錄存在於索引中．舉例: 若是惟一性索引創建在表的A列和B列上, 而且表中存在一條記錄的A,B值爲(123,null) , ORACLE將不接受下一條具備相同A,B值（123,null）的記錄(插入). 然而若是全部的索引列都爲空，ORACLE將認爲整個鍵值爲空而空不等於空. 所以你能夠插入1000 條具備相同鍵值的記錄,固然它們都是空! 由於空值不存在於索引列中,因此WHERE子句中對索引列進行空值比較將使ORACLE停用該索引.

低效: (索引失效)
SELECT * FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;

高效: (索引有效)
SELECT  * FROM DEPARTMENT WHERE DEPT_CODE >=0;

 

25.避免改變索引列的類型.:

當比較不一樣數據類型的數據時, ORACLE自動對列進行簡單的類型轉換.
假設 EMPNO是一個數值類型的索引列.

SELECT … FROM EMP WHERE EMPNO = ‘123'
實際上,通過ORACLE類型轉換, 語句轉化爲:

SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123')
幸運的是,類型轉換沒有發生在索引列上,索引的用途沒有被改變.
如今,假設EMP_TYPE是一個字符類型的索引列.

SELECT … FROM EMP WHERE EMP_TYPE = 123
這個語句被ORACLE轉換爲:

select … from EMP WHERETO_NUMBER(EMP_TYPE)=123
由於內部發生的類型轉換, 這個索引將不會被用到! 爲了不ORACLE對你的SQL進行隱式的類型轉換, 最好把類型轉換用顯式表現出來. 注意當字符和數值比較時, ORACLE會優先轉換數值類型到字符類型

 

26.若是檢索數據量超過30%的表中記錄數.使用索引將沒有顯著的效率提升. 

b. 在特定狀況下, 使用索引也許會比全表掃描慢, 但這是同一個數量級上的區別. 而一般狀況下,使用索引比全表掃描要塊幾倍乃至幾千倍!

 

27.用Explain Plan分析SQL語句

EXPLAIN PLAN 是一個很好的分析SQL語句的工具, 它甚至能夠在不執行SQL的狀況下分析語句. 經過分析, 咱們就能夠知道ORACLE是怎麼樣鏈接表, 使用什麼方式掃描表(索引掃描或全表掃描)以及使用到的索引名稱。

 

28.對UNION的優化

因爲UNION會對查詢結果進行排序，並且過濾重複記錄，所以其執行效率沒有UNION ALL高。 UNION操做會使用到SORT_AREA_SIZE內存塊，所以對這塊內存的優化也很是重要。

可使用下面的SQL來查詢排序的消耗量 ：

select *
from V$SYSSTAT
where name like 'sort%'

 

 

29.鏈接多個掃描

若是對一個列和一組有限的值進行比較，優化器可能執行屢次掃描並對結果進行合併鏈接。

舉例：

SELECT *
FROM LODGING
WHERE MANAGER IN (‘BILL GATES’, ’KEN MULLER’)
優化器可能將它轉換成如下形式：

SELECT *
FROM LODGING
WHERE MANAGER = ‘BILL GATES’
OR MANAGER = ’KEN MULLER’

 

30.使用日期

當使用日期時，須要注意若是有超過5位小數加到日期上，這個日期會進到下一天!
select TO_DATE('20010101','yyyymmdd')+0.99999
from DUAL;
Returns：
02-1月 -01

select TO_DATE('20010101','yyyymmdd')+0.999995
from DUAL;
RETURNS：
02-1月 -01

 

31.使用顯示遊標(CURSORS)

使用隱式的遊標，將會執行兩次操做。第一次檢索記錄，第二次檢查TOO MANY ROWS 這個exception。而顯式遊標不執行第二次操做。

 

32.優化EXPORT和IMPORT

使用較大的BUFFER(好比10MB , 10,240,000)能夠提升EXPORT和IMPORT的速度.

ORACLE將盡量地獲取你所指定的內存大小,即便在內存不知足,也不會報錯.這個值至少要和表中最大的列至關,不然列值會被截斷.

譯者按:

能夠確定的是, 增長BUFFER會大大提升EXPORT , IMPORT的效率. (曾經碰到過一個CASE, 增長BUFFER後,IMPORT/EXPORT快了10倍!)

做者可能犯了一個錯誤: 「這個值至少要和表中最大的列至關,不然列值會被截斷. 「

其中最大的列也許是指最大的記錄大小.

 

33.分離表和索引

老是將你的表和索引創建在不一樣的表空間內（TABLESPACES）。決不要將不屬於ORACLE內部系統的對象存放到SYSTEM表空間裏。確保數據表空間和索引表空間置於不一樣的硬盤上。