ORACLE的解析器按照從右至左的順序處理FROM子句中的表名,因此FROM子句中寫在最後的表(基礎資料表 driving table)將被最先處理. 在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎資料表.當ORACLE處理多個表時, 會運用排序及合并的方式串連它們.首先,掃描第一個表(FROM子句中最後的那個表)並對記錄進行派序,然後掃描第二個表(FROM子句中最後第二個表),最後將所有從第二個表中檢索出的記錄與第一個表中合適記錄進行合并.
例如: A表2萬條記錄,B表1條記錄
選擇B作為基礎資料表 (最好的方法)
select count(*) from a ,b執行時間0.96秒
選擇TAB2作為基礎資料表 (不佳的方法)
select count(*) from b,a 執行時間26.09秒
SELECT子句中避免使用 ‘ * ‘
當你想在SELECT子句中列出所有的COLUMN時,使用動態SQL列引用 ‘*’ 是一個方便的方法.不幸的是,這是一個非常低效的方法. 實際上,ORACLE在解析的過程中, 會將’*’ 依次轉換成所有的列名, 這個工作是通過查詢資料字典完成的, 這意味著將耗費更多的時間.
<> 操作符(不等於)
不等於操作符是永遠不會用到索引的,因此對它的處理只會產生全表掃描。
推薦方案:用其它相同功能的操作運算代替,如
a<>0 改為 a>0 or a<0
a<>’’ 改為 a>’’
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’;
LIKE操作符
LIKE操作符可以應用萬用字元查詢,裡面的萬用字元組合可能達到幾乎是任意的查詢,但是如果用得不好則會產生效能上的問題,如LIKE ‘%5400%’ 這種查詢不會引用索引,而LIKE ‘X5400%’則會引用範圍索引。一個實際例子:用YW_YHJBQK表中營業編號後面的戶標識號可來查詢營業編號 YY_BH LIKE ‘%5400%’ 這個條件會產生全表掃描,如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 則會利用YY_BH的索引進行兩個範圍的查詢,效能肯定大大提高。
盡量多使用COMMIT 只要有可能,在程式中盡量多使用COMMIT, 這樣程式的效能得到提高,需求也會因為COMMIT所釋放的資源而減少:
COMMIT所釋放的資源:
a. 復原段上用於恢複資料的資訊.
b. 被程式語句獲得的鎖
c. redo log buffer 中的空間
d. ORACLE為管理上述3種資源中的內部花費
減少對錶的查詢,在含有子查詢的SQL語句中,要特別注意減少對錶的查詢.
盡量多使用表的別名(Alias),當在SQL語句中串連多個表時, 請使用表的別名並把別名首碼於每個Column上.這樣一來,就可以減少解析的時間並減少那些由Column歧義引起的語法錯誤.
IN 操作符
用IN寫出來的SQL的優點是比較容易寫及清晰易懂,這比較適合現代軟體開發的風格。
但是用IN的SQL效能總是比較低的,從ORACLE執行的步驟來分析用IN的SQL與不用IN的SQL有以下區別:
ORACLE試圖將其轉換成多個表的串連,如果轉換不成功則先執行IN裡面的子查詢,再查詢外層的表記錄,如果轉換成功則直接採用多個表的串連方式查詢。由此可見用IN的SQL至少多了一個轉換的過程。一般的SQL都可以轉換成功,但對於含有分組統計等方面的SQL就不能轉換了。
推薦方案:在業務密集的SQL當中盡量不採用IN操作符。
NOT IN操作符
此操作是強列推薦不使用的,因為它不能應用表的索引。
推薦方案:用NOT EXISTS 或(外串連+判斷為空白)方案代替。