Oracle性能優化
SQL共享原理程序員
ORACLE將執行過的SQL語句存放在內存的共享池(shared buffer pool)中，能夠被全部的數據庫用戶共享。當你執行一個SQL語句(有時被稱爲一個遊標)時,若是它和以前的執行過的語句徹底相同,ORACLE就能很快得到已經被解析的語句以及最好的 執行路徑. 這個功能大大地提升了SQL的執行性能並節省了內存的使用。sql
爲了避免重複解析相同的SQL語句，在第一次解析以後，Oracle將SQL語句存放在內存中。這塊位於系統全局區域SGA(systemglobal area)的共享池(shared buffer poo1)中的內存能夠被全部的數據庫用戶共享。所以，當你執行一個SQL語句(有時被稱爲一個遊標)時，若是它和以前執行過的語句徹底相同，Oracle就能很快得到已經被解析的語句以及最好的執行方案。Oracle的這個功能大大地提升了SQL的執行性能並節省了內存的使用。數據庫
惋惜的是，Oracle只對簡單的表提供高速緩衝(cache bufferiIlg)，這個功能並不適用於多表鏈接查詢。數據庫管理員必須在啓動參數文件中爲這個區域設置合適的參數，當這個內存區域越大，就能夠保留更多的語句，固然被共享的可能性也就越大了。當向Oracle提交一個SQL語句時，Oracle會首先在這塊內存中查找相同的語句。數組
要使用內存中共享池的SQL，必須知足如下條件：當前被執行的語句和共享池中的語句必須徹底相同 （包括大小寫、空格、換行等），兩個語句所指的對象必須徹底相同 （同義詞與表是不一樣的對象）兩個SQL語句中必須使用相同的名字的綁定變量(bind variables) 。Oracle對二者採起的是一種嚴格匹配策略，要達成共享。SQL語句必須徹底相同(包括空格、換行等)。緩存
可以使用共享的語句必須知足三個條件：
① 字符級的比較。
當前被執行的語句和共享池中的語句必須徹底相同。
例如： SELECT * FROM ATABLE;和下面每個SQL語句都不一樣：
SELECT *from ATABLE;
Select * From Atable;
② 語句所指對象必須徹底相同 即兩條SQL語句操做的數據庫對象必須同一。
③語句中必須使用相同命名的綁定變量。如：第一組的兩個SQL語句是相同的，能夠共享；而第二組中兩個語句不一樣，即便在運行時賦予不一樣的綁定變量以相同的值：
●第一組 select pin，name from people where pin = ：blk1.pin；
select pin，name from people where pin =：blk1.pin；
●第二組 select pin，name from people where pin =：blk1.ot_jnd；
select pin，name from people where pin = ：blk1.ov_jnd；服務器
爲何要綁定變量？網絡
下面這個語句每執行一次就須要在SHARE POOL 硬解析一次，一百萬用戶就是一百萬次，消耗CPU和內存，若是業務量大，極可能致使宕庫……
若是綁定變量，則只須要硬解析一次，重複調用便可。
select * from dConMsg where contract_no = 32013484095139oracle
硬解析即整個SQL語句的執行須要完徹底全的解析，生成執行計劃。而硬解析，生成執行計劃須要耗用CPU資源，以及SGA資源。在此不得不提的是對庫緩存中閂的使用。閂是鎖的細化，能夠理解爲是一種輕量級的串行化設備。當進程申請到閂後，則這些閂用於保護共享內存的數在同一時刻不會被兩個以上的進程修改。在硬解析時，須要申請閂的使用，而閂的數量在有限的狀況下須要等待。大量的閂的使用由此形成須要使用閂的進程排隊越頻繁，性能則逾低下。分佈式
綁定變量解決硬解析問題ide
未使用綁定變量的語句
sprintf(sqlstr, "insert into scott.test1 (num1, num2) values (%d,%d)",n_var1, n_var2);
EXEC SQL EXECUTE IMMEDIATE :sqlstr ;
EXEC SQL COMMIT;
使用綁定變量的語句
strcpy(sqlstr, "insert into test (num1, num2) values (:v1, :v2)");
EXEC SQL PREPARE sql_stmt FROM :sqlstr;
EXEC SQL EXECUTE sql_stmt USING :n_var1, :n_var2;
EXEC SQL COMMIT;
SQL優化
SQL優化的通常性原則
目標：
- 減小服務器資源消耗（主要是磁盤IO）；
設計方面：
- 儘可能依賴oracle的優化器，併爲其提供條件；
- 合適的索引，索引的雙重效應，列的選擇性；
編碼方面：
- 利用索引，避免大表FULL TABLE SCAN；
- 合理使用臨時表；
- 避免寫過於複雜的sql，不必定非要一個sql解決問題；
- 在不影響業務的前提下減少事務的粒度；
優化歸納
- 建立表的時候。應儘可能創建主鍵，儘可能根據實際須要調整數據表的PCTFREE和PCTUSED參數；大數據表刪除，用truncate table代替delete。
- 合理使用索引，在OLTP應用中一張表的索引不要太多。數據重複量大的列不要創建二叉樹索引，能夠採用位圖索引；組合索引的列順序儘可能與查詢條件列順序保持一致；對於數據操做頻繁的表，索引須要按期重建，以減小失效的索引和碎片。
- 查詢儘可能用肯定的列名，少用*號。select count(key)from tab where key> 0性能優於select count(*)from tab；
- 儘可能少嵌套子查詢，這種查詢會消耗大量的CPU資源；對於有比較多or運算的查詢，建議分紅多個查詢，用union all聯結起來；多表查詢的查詢語句中，選擇最有效率的表名順序。Oracle解析器對錶解析從右到左，因此記錄少的表放在右邊。
- 儘可能多用commit語句提交事務，能夠及時釋放資源、解鎖、釋放日誌空間、減小管理花費；在頻繁的、性能要求比較高的數據操做中，儘可能避免遠程訪問，如數據庫鏈等，訪問頻繁的表能夠常駐內存：alter table．．．cache；
隨着數據庫中數據的增長，系統的響應速度就成爲目前系統須要解決的最主要的問題之一。系統優化中一個很重要的方面就是SQL語句的優化。對於大量數據，劣質SQL語句和優質SQL語句之間的速度差異能夠達到上百倍，對於一個系統不是簡單地能實現其功能就可，而是要寫出高質量的SQL語句，提升系統的可用性。在多數狀況下，Oracle使用索引來更快地遍歷表，優化器主要根據定義的索引來提升性能。若是在SQL語句的where子句中寫的SQL代碼不合理，就會形成優化器刪去索引而使用全表掃描，通常就這種SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時咱們應清楚優化器根據何種原則來使用索引，這有助於寫出高性能的SQL語句。SQL語句的編寫原則和SQL語句的優化，請跟我一塊兒學習如下幾方面：
- 避免複雜的多表關聯
select …
from user_files uf, df_money_files dm,
cw_charge_record cc
where
uf.user_no = dm.user_no
and dm.user_no = cc.user_no
and ……
and not exists(select …)
很難優化，隨着數據量的增長性能的風險很大。
- 避免使用 '* '
當你想在SELECT子句中列出全部的COLUMN時,使用動態SQL列引用 ‘*’ 是一個方便的方法。不幸的是,這是一個常低效的方法。實際上,ORACLE在解析的過程當中，會將’*’ 依次轉換成全部的列名，這個工做是經過查詢數據字典完成的， 這意味着將耗費更多的時間；只提取你所要使用的列，使用別名可以加快解析速度；
- 避免使用耗費資源的操做
帶有DISTINCT，UNION，MINUS，INTERSECT，ORDER BY的SQL語句會啓動SQL引擎執行耗費資源的排序(SORT)功能。DISTINCT須要一次排序操做， 而其餘的至少須要執行兩次排序。
一般, 帶有UNION， MINUS， INTERSECT的SQL語句均可以用其餘方式重寫。
- 用EXISTS替換DISTINCT
例如:
低效:
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);
- 用UNION-ALL 替換UNION ( if possible)
當SQL語句須要UNION兩個查詢結果集合時,這兩個結果集合會以UNION-ALL的方式被合併, 而後在輸出最終結果前進行排序.
舉例:
低效：
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95’
UNION
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95’
高效:
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95’
UNION ALL
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95’
- 自動選擇索引
若是表中有兩個以上（包括兩個）索引，其中有一個惟一性索引，而其餘是非惟一性在這種狀況下，ORACLE將使用惟一性索引而徹底忽略非惟一性索引．
舉例:
SELECT ENAME
FROM EMP
WHERE EMPNO = 2326
AND DEPTNO = 20 ;
這裏，只有EMPNO上的索引是惟一性的，因此EMPNO索引將用來檢索記錄．
TABLE ACCESS BY ROWID ON EMP
INDEX UNIQUE SCAN ON EMP_NO_IDX
- 至少要包含組合索引的第一列
若是索引是創建在多個列上， 只有在它的第一個列(leading column)被where子句引用時，優化器纔會選擇使用該索引。
SQL> create table multiindexusage ( inda number , indb number , descr varchar2(10));
Table created.
SQL> create index multindex on multiindexusage(inda,indb);
Index created.
SQL> set autotrace traceonly
SQL> select * from multiindexusage where inda = 1;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'MULTIINDEXUSAGE'
2 1 INDEX (RANGE SCAN) OF 'MULTINDEX' (NON-UNIQUE)
SQL> select * from multiindexusage where indb = 1;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'MULTIINDEXUSAGE'
很明顯，當僅引用索引的第二個列時，優化器使用了全表掃描而忽略了索引。
- 避免在索引列上使用函數
WHERE子句中，若是索引列是函數的一部分。優化器將不使用索引而使用全表掃描。
舉例:
低效：
SELECT …
FROM DEPT
WHERE SAL * 12 > 25000;
高效:
SELECT …
FROM DEPT
WHERE SAL > 25000/12;
- 避免使用前置通配符
WHERE子句中， 若是索引列所對應的值的第一個字符由通配符(WILDCARD)開始， 索引將不被採用。
SELECT USER_NO,USER_NAME,ADDRESS
FROM USER_FILES
WHERE USER_NO LIKE '%109204421';
在這種狀況下，ORACLE將使用全表掃描。
- 避免在索引列上使用NOT
一般，咱們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響. 當ORACLE」遇到」NOT,他就會中止使用索引轉而執行全表掃描.
舉例:
低效: (這裏,不使用索引)
SELECT …
FROM DEPT
WHERE DEPT_CODE <> 0;
高效: (這裏,使用了索引)
SELECT …
FROM DEPT
WHERE DEPT_CODE > 0;
- 避免在索引列上使用 IS NULL和IS NOT NULL
避免在索引中使用任何能夠爲空的列，ORACLE將沒法使用該索引 ．對於單列索引，若是列包含空值，索引中將不存在此記錄. 對於複合索引，若是每一個列都爲空，索引中一樣不存在此記錄. 若是至少有一個列不爲空，則記錄存在於索引中．
若是惟一性索引創建在表的A列和B列上, 而且表中存在一條記錄的A,B值爲(123,null) , ORACLE將不接受下一條具備相同A,B值（123,null）的記錄(插入). 然而若是全部的索引列都爲空，ORACLE將認爲整個鍵值爲空而空不等於空. 所以你能夠插入1000條具備相同鍵值的記錄,固然它們都是空!
由於空值不存在於索引列中,因此WHERE子句中對索引列進行空值比較將使ORACLE停用該索引.
任何在where子句中使用is null或is not null的語句優化器是不容許使用索引的。
- 避免出現索引列自動轉換
當比較不一樣數據類型的數據時, ORACLE自動對列進行簡單的類型轉換.
假設EMP_TYPE是一個字符類型的索引列.
SELECT USER_NO,USER_NAME,ADDRESS
FROM USER_FILES
WHERE USER_NO = 109204421
這個語句被ORACLE轉換爲:
SELECT USER_NO,USER_NAME,ADDRESS
FROM USER_FILES
WHERE TO_NUMBER(USER_NO) = 109204421
由於內部發生的類型轉換, 這個索引將不會被用到!
- 在查詢時儘可能少用格式轉換
如用 WHERE a.order_no = b.order_no不用WHERE TO_NUMBER (substr(a.order_no, instr(b.order_no, '.') - 1)
- 減小訪問數據庫的次數
當執行每條SQL語句時， ORACLE在內部執行了許多工做，解析SQL語句，估算索引的利用率，綁定變量，讀數據塊等等。因而可知，減小訪問數據庫的次數 , 就能實際上減小ORACLE的工做量。
- 使用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%’;
- 減小對錶的查詢
在含有子查詢的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)
- WHERE子句中的鏈接順序
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理, 當在WHERE子句中有多個表聯接時，WHERE子句中排在最後的表應當是返回行數可能最少的表，有過濾條件的子句應放在WHERE子句中的最後。
如：設從emp表查到的數據比較少或該表的過濾條件比較肯定，能大大縮小查詢範圍，則將最具備選擇性部分放在WHERE子句中的最後：
select * from emp e,dept d
where d.deptno >10 and e.deptno =30 ;
若是dept表返回的記錄數較多的話，上面的查詢語句會比下面的查詢語句響應快得多。
select * from emp e,dept d
where e.deptno = 30 and d.deptno >10 ;
最好不要在WHERE子句中使用函或表達式，若是要使用的話，最好統一使用相同的表達式或函數，這樣便於之後使用合理的索引。
- Order by語句
ORDER BY語句決定了Oracle如何將返回的查詢結果排序。Order by語句對要排序的列沒有什麼特別的限制，也能夠將函數加入列中（象聯接或者附加等）。任何在Order by語句的非索引項或者有計算表達式都將下降查詢速度。仔細檢查order by語句以找出非索引項或者表達式，它們會下降性能。解決這個問題的辦法就是重寫order by語句以使用索引，也能夠爲所使用的列創建另一個索引，同時應絕對避免在order by子句中使用表達式。
- 聯接列
對於有聯接的列，即便最後的聯接值爲一個靜態值，優化器是不會使用索引的。
select * from employss
where
first_name||''||last_name ='Beill Cliton';
系統優化器對基於last_name建立的索引沒有使用。
當採用下面這種SQL語句的編寫，Oracle系統就能夠採用基於last_name建立的索引。
select * from employee
where
first_name ='Beill' and last_name ='Cliton';
- 帶通配符（%）的like語句 *
通配符（%）在搜尋詞首出現，Oracle系統不使用last_name的索引。
select * from employee where last_name like '%cliton%';
在不少狀況下可能沒法避免這種狀況，可是必定要心中有底，通配符如此使用會下降查詢速度。然而當通配符出如今字符串其餘位置時，優化器就能利用索引。在下面的查詢中索引獲得了使用：
select * from employee where last_name like 'c%';
- 用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
順序
WHERE > GROUP > HAVING
- 用NOT EXISTS 替代 NOT IN
在子查詢中,NOT IN子句將執行一個內部的排序和合並. 不管在哪一種狀況下,NOT IN都是最低效的 (由於它對子查詢中的表執行了一個全表遍歷)。
使用NOT EXISTS 子句能夠有效地利用索引。儘量使用NOT EXISTS來代替NOT IN，儘管兩者都使用了NOT（不能使用索引而下降速度），NOT EXISTS要比NOT IN查詢效率更高。
例如:
deptno NOT IN (SELECT deptno FROM emp);
NOT EXISTS
(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno);
2要比1的執行性能好不少。
由於1中對emp進行了full table scan,這是很浪費時間的操做。並且1中沒有用到emp的index， 由於沒有where子句。而2中的語句對emp進行的是縮小範圍的查詢。
- *用索引提升效率
索引是表的一個概念部分,用來提升檢索數據的效率，ORACLE使用了一個複雜的自平衡B-tree結構. 一般,經過索引查詢數據比全表掃描要快. 當ORACLE找出執行查詢和Update語句的最佳路徑時,ORACLE優化器將使用索引. 一樣在聯結多個表時使用索引也能夠提升效率. 另外一個使用索引的好處是,它提供了主鍵(primary key)的惟一性驗證。
一般, 在大型表中使用索引特別有效. 固然,你也會發現, 在掃描小表時,使用索引一樣能提升效率. 雖然使用索引能獲得查詢效率的提升,可是咱們也必須注意到它的代價. 索引須要空間來存儲,也須要按期維護, 每當有記錄在表中增減或索引列被修改時, 索引自己也會被修改. 這意味着每條記錄的INSERT , DELETE , UPDATE將爲此多付出4 , 5 次的磁盤I/O . 由於索引須要額外的存儲空間和處理,那些沒必要要的索引反而會使查詢反應時間變慢.。按期的重構索引是有必要的。
- 避免在索引列上使用計算
WHERE子句中，若是索引列是函數的一部分．優化器將不
使用索引而使用全表掃描．
低效：
SELECT … FROM DEPT WHERE SAL * 12 > 25000;
高效:
SELECT … FROM DEPT WHERE SAL > 25000/12;
- 用>= 替代 >
若是DEPTNO上有一個索引。
高效:
SELECT *
FROM EMP
WHERE DEPTNO >=4
低效:
SELECT *
FROM EMP
WHERE DEPTNO >3
- 經過使用>=、<=等，避免使用NOT命令
例子：
雖然這兩種查詢的結果同樣，可是第二種查詢方案會比第一種查詢方案更快些。第二種查詢容許Oracle對salary列使用索引，而第一種查詢則不能使用索引。
- 若是有其它辦法，不要使用子查詢
- 外部聯接"+"的用法
外部聯接"+"按其在"="的左邊或右邊分左聯接和右聯接。若不帶"+"運算符的表中的一個行不直接匹配於帶"+"預算符的表中的任何行，則前者的行與後者中的一個空行相匹配並被返回。利用外部聯接"+"，能夠替代效率十分低下的 not in 運算，大大提升運行速度。例如，下面這條命令執行起來很慢：
- 儘可能多使用COMMIT
事務是消耗資源的，大事務還容易引發死鎖
COMMIT所釋放的資源:
- 回滾段上用於恢復數據的信息.
- 被程序語句得到的鎖
- redo log buffer 中的空間
- ORACLE爲管理上述3種資源中的內部花費
- 用TRUNCATE替代DELETE
當刪除表中的記錄時,在一般狀況下, 回滾段(rollback segments ) 用來存放能夠被恢復的信息. 若是你沒有COMMIT事務,ORACLE會將數據恢復到刪除以前的狀態(準確地說是恢復到執行刪除命令以前的情況)
而當運用TRUNCATE時, 回滾段再也不存聽任何可被恢復的信息.當命令運行後,數據不能被恢復.所以不多的資源被調用,執行時間也會很短。
- 計算記錄條數
和通常的觀點相反, count(*
比count(1)稍快 , 固然若是能夠經過索引檢索,對索引列的計數仍舊是最快的。
例如 COUNT(EMPNO)
- 字符型字段的引號
好比有的表PHONE_NO字段是CHAR型,並且建立有索引，
但在WHERE條件中忘記了加引號，就不會用到索引。
WHERE PHONE_NO=‘13920202022’
WHERE PHONE_NO=13920202022
SQL語句的處理過程
1. DML語句處理(insert, update, delete)
第2步:分析語句(Parse the Statement)
語法分析分別執行下列操做：
- 翻譯SQL語句，驗證它是合法的語句，即書寫正確
- 實現數據字典的查找，以驗證是否符合表和列的定義
- 在所要求的對象上獲取語法分析鎖，使得在語句的語法分析過程當中不改變這些對象的定義
- 驗證爲存取所涉及的模式對象所需的權限是否知足
- 決定此語句最佳的執行計劃
- 將它裝入共享SQL區
- 對分佈的語句來講，把語句的所有或部分路由到包含所涉及數據的遠程節點
以上任何一步出錯誤，都將致使語句報錯，停止執行。
- 只有在共享池中不存在等價SQL語句的狀況下，纔對SQL語句做語法分析。在這種狀況下，數據庫內核從新爲該語句分配新的共享SQL區，並對語句進行語法分析。進行語法分析須要耗費較多的資源，因此要儘可能避免進行語法分析，這是優化的技巧之一。
- 語法分析階段包含了無論此語句將執行多少次，而只需分析一次的處理要求。Oracle只對每一個SQL語句翻譯一次，在之後再次執行該語句時，只要該語句還在共享SQL區中，就能夠避免對該語句從新進行語法分析，也就是此時能夠直接使用其對應的執行計劃對數據進行存取。這主要是經過綁定變量(bind variable)實現的，也就是咱們常說的共享SQL，後面會給出共享SQL的概念。
- 雖然語法分析驗證了SQL語句的正確性，但語法分析只能識別在SQL語句執行以前所能發現的錯誤(如書寫錯誤、權限不足等)。所以，有些錯誤經過語法分析是抓不到的。例如，在數據轉換中的錯誤或在數據中的錯（如企圖在主鍵中插入重複的值）以及死鎖等均是隻有在語句執行階段期間才能遇到和報告的錯誤或狀況。
查詢與其它類型的SQL語句不一樣，由於在成功執行後做爲結果將返回數據。
第3步: 描述查詢結果(Describe Results of a Query)
描述階段只有在查詢結果的各個列是未知時才須要；例如，當查詢由用戶交互地輸入須要輸出的列名。在這種狀況要用描述階段來決定查詢結果的特徵（數據類型，長度和名字）。
第4步: 定義查詢的輸出數據(Define Output of a Query)
在查詢的定義階段，你指定與查詢出的列值對應的接收變量的位置、大小和數據類型，這樣咱們經過接收變量就能夠獲得查詢結果。若是必要的話，Oracle會自動實現數據類型的轉換。這是將接收變量的類型與對應的列類型相比較決定的。
第5步: 綁定變量(Bind Any Variables)
- Oracle知道了SQL語句的意思，但仍沒有足夠的信息用於執行該語句。Oracle 須要獲得在語句中列出的全部變量的值。在該例中，Oracle須要獲得對department_id列進行限定的值。獲得這個值的過程就叫綁定變量(binding variables)
- 此過程稱之爲將變量值捆綁進來。程序必須指出能夠找到該數值的變量名（該變量被稱爲捆綁變量，變量名實質上是一個內存地址，至關於指針）。應用的最終用戶可能並無發覺他們正在指定捆綁變量，由於Oracle 的程序可能只是簡單地指示他們輸入新的值，其實這一切都在程序中自動作了。
- 由於你指定了變量名，在你再次執行以前無須從新捆綁變量。你能夠改變綁定變量的值，而Oracle在每次執行時，僅僅使用內存地址來查找此值。
- 若是Oracle 須要實現自動數據類型轉換的話（除非它們是隱含的或缺省的），你還必須對每一個值指定數據類型和長度。關於這些信息能夠參考oracle的相關文檔，如Oracle Call Interface Programmer's Guide
第6步: 並行執行語句(Parallelize the Statement )
第7步: 執行語句(Run the Statement)
第8步: 取出查詢的行(Fetch Rows of a Query)
第9步: 關閉遊標(Close the Cursor)SQL語句處理的最後一個階段就是關閉遊標。
2. DDL 語句處理(create .. , drop .. , alter .. , )(insert, update, delete)
Oralce優化器
Oracle的優化器共有3種模式：RULE (基於規則)、COST(基於成本)、CHOOSE(基於選擇)。
設置缺省的優化器的方法，是在啓動參數文件中針對OPTIMIZER_ MODE參數的各類聲明進行選擇，如RULE、COST、CHOOSE、ALL_ ROWS、FIRST_ ROWS。固然也能夠在SQL語句級別或是會話級別對其進行覆蓋。
爲了使用基於成本的優化器(CBO，Cost—Based Optimizer)，必須常常運行analyze命令，以增長數據庫中的對象統計信息(object statistics)的準確性。
若是數據庫的優化器模式設置爲基於選擇，那麼實際的優化器模式將和是否運行過analyze命令有關。若是數據表已經被analyze過，優化器模式將自動切換成CBO，反之，數據庫將採用RULE形式的優化器。在缺省狀況下，Oracle採用CHOOSE優化器。爲避免那些沒必要要的全表掃描，必須儘可能避免使用CHOOSE優化器，而直接採用基於規則或者基於成本的優化器。
2 種類型的優化器：
基於規則的優化器
基於代價的優化器。
不一樣之處：取得代價的方法與衡量代價的大小不一樣。
基於規則的優化器 -- Rule Based (Heuristic) Optimization(簡稱RBO)
基於規則的優化器中採用啓發式的方法(Heuristic Approach)或規則(Rules)來生成執行計劃。例如，若是一個查詢的where條件(where clause)包含一個謂詞(predicate，其實就是一個判斷條件，如」=」, 「>」, 」<」等)，並且該謂詞上引用的列上有有效索引，那麼優化器將使用索引訪問這個表，而不考慮其它因素，如表中數據的多少、表中數據的易變性、索引的可選擇性等。此時數據庫中沒有關於表與索引數據的統計性描述，如表中有多上行，每行的可選擇性等。優化器也不考慮實例參數，如multi block i/o、可用排序內存的大小等，因此優化器有時就選擇了次優化的計劃做爲真正的執行計劃，致使系統性能不高。如，對於 select * from emp where deptno = 10;若是是使用基於規則的優化器，並且deptno列上有有效的索引，則會經過deptno列上的索引來訪問emp表。在絕大多數狀況下，這是比較高效的，可是在一些特殊狀況下，使用索引訪問也有比較低效的時候，現舉例說明： 1) emp表比較小，該表的數據只存放在幾個數據塊中。此時使用全表掃描比使用索引訪問emp表反而要好。由於表比較小，極有可能數據全在內存中，因此此時作全表掃描是最快的。而若是使用索引掃描，須要先從索引中找到符合條件記錄的rowid，而後再一一根據這些rowid從emp中將數據取出來，在這種條件下，效率就會比全表掃描的效率要差一些。2) emp表比較大時，並且deptno = 10條件能查詢出表中大部分的數據如(50%)。如該表共有4000萬行數據，共放在有500000個數據塊中，每一個數據塊爲8k，則該表共有約4G，則這麼多的數據不可能全放在內存中，絕大多數須要放在硬盤上。此時若是該查詢經過索引查詢，則是你夢魘的開始。db_file_multiblock_read_count參數的值200。若是採用全表掃描，則須要500000/db_file_multiblock_read_count=500000/200=2500次I/O。可是若是採用索引掃描，假設deptno列上的索引都已經cache到內存中，因此能夠將訪問索引的開銷忽略不計。由於要讀出4000萬x 50% = 2000萬數據，假設在讀這2000萬數據時，有99.9%的命中率，則仍是須要20000次I/O,比上面的全表掃描須要的2500次多多了，因此在這種狀況下，用索引掃描反而性能會差不少。在這樣的狀況下，用全表掃描的時間是固定的，可是用索引掃描的時間會隨着選出數據的增多使查詢時間相應的延長。
基於代價的優化器 -- Cost Based Optimization(簡稱CBO)
Oracle把一個代價引擎(Cost Engine)集成到數據庫內核中，用來估計每一個執行計劃須要的代價，該代價將每一個執行計劃所耗費的資源進行量化，從而CBO能夠根據這個代價選擇出最優的執行計劃。查詢耗費的資源能夠被分紅3個基本組成部分：I/O代價、CPU代價、network代價。
判斷當前數據庫使用何種優化器
Oracle執行計劃
爲了避免重複解析相同的SQL語句(由於解析操做比較費資源，會致使性能降低)，在第一次解析以後，ORACLE將SQL語句及解析後獲得的執行計劃存放在內存中。這塊位於系統全局區域SGA(system global area)的共享池(shared buffer pool)中的內存能夠被全部的數據庫用戶共享。所以，當你執行一個SQL語句(有時被稱爲一個遊標)時，若是該語句和以前的執行過的某一語句徹底相同，而且以前執行的該語句與其執行計劃仍然在內存中存在，則ORACLE就不須要再進行分析，直接獲得該語句的執行路徑。ORACLE的這個功能大大地提升了SQL的執行性能並大大節省了內存的使用。使用這個功能的關鍵是將執行過的語句儘量放到內存中，因此這要求有大的共享池(經過設置shared buffer pool參數值)和儘量的使用綁定變量的方法執行SQL語句。
Rowid的概念
rowid是一個僞列，既然是僞列，那麼這個列就不是用戶定義，而是系統本身給加上的。對每一個表都有一個rowid的僞列，可是表中並不物理存儲ROWID列的值。不過你能夠像使用其它列那樣使用它，可是不能刪除該列，也不能對該列的值進行修改、插入。一旦一行數據插入數據庫，則rowid在該行的生命週期內是惟一的，即即便該行產生行遷移，行的rowid也不會改變。
爲何使用Rowid
rowid對訪問一個表中的給定的行提供了最快的訪問方法，經過ROWID能夠直接定位到相應的數據塊上，而後將其讀到內存。咱們建立一個索引時，該索引不但存儲索引列的值，並且也存儲索引值所對應的行的ROWID，這樣咱們經過索引快速找到相應行的ROWID後，經過該ROWID，就能夠迅速將數據查詢出來。這也就是咱們使用索引查詢時，速度比較快的緣由。
在ORACLE8之前的版本中，ROWID由FILE 、BLOCK、ROW NUMBER構成。隨着oracle8中對象概念的擴展，ROWID發生了變化，ROWID由OBJECT、FILE、BLOCK、ROW NUMBER構成。利用DBMS_ROWID能夠將rowid分解成上述的各部分，也能夠將上述的各部分組成一個有效的rowid。
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, col3, ……)，則咱們稱idx_emp索引爲組合索引。在組合索引中有一個重要的概念：引導列(leading column)，在上面的例子中，col1列爲引導列。當咱們進行查詢時可使用」where col1 = ? 」，也可使用」where col1 = ? and col2 = ?」，這樣的限制條件都會使用索引，可是」where col2 = ? 」查詢就不會使用該索引。因此限制條件中包含先導列時，該限制條件纔會使用該組合索引。
可選擇性(selectivity)
比較一下列中惟一鍵的數量和表中的行數，就能夠判斷該列的可選擇性。若是該列的」惟一鍵的數量/表中的行數」的比值越接近1，則該列的可選擇性越高，該列就越適合建立索引，一樣索引的可選擇性也越高。在可選擇性高的列上進行查詢時，返回的數據就較少，比較適合使用索引查詢。
|
爲了執行語句，Oracle可能必須實現許多步驟。這些步驟中的每一步多是從數據庫中物理檢索數據行，或者用某種方法準備數據行，供發出語句的用戶使用。Oracle用來執行語句的這些步驟的組合被稱之爲執行計劃。執行計劃是SQL優化中最爲複雜也是最爲關鍵的部分，只有知道了ORACLE在內部究竟是如何執行該SQL語句後，才能知道優化器選擇的執行計劃是否爲最優的。執行計劃對於DBA來講，就象財務報表對於財務人員同樣重要。因此咱們面臨的問題主要是：
顯示下面SQL語句的執行計劃。 ¨SELECT ename, job, sal, dname ¨FROM emp, dept
¨WHERE emp.deptno = derpt.deptno
¨AND NOT EXISTS
¨( SELECT *
¨FROM salgrade
¨WHERE emp.sal BETWEEN losal AND hisal );
此語句查詢薪水不在任何建議薪水範圍內的全部僱員的名字，工做，薪水和部門名。 如圖顯示了上例執行計劃的圖形表示： 執行計劃的步驟
實現執行計劃步驟的順序執行計劃中的步驟不是按照它們編號的順序來實現的：Oracle首先實現上圖樹結構圖形裏做爲葉子出現的那些步驟(例如步驟三、五、6)。由每一步返回的行稱爲它下一步驟的行源。而後Oracle實現父步驟。 Oracle如下列順序實現這些步驟：
一、Oracle實現步驟５，並將結果ROWID返回給第４步。
對於以上的操做過程，可使用first_rows做爲優化目標以便於實現快速響應用戶的請求。有些父步驟在它們被實現以前須要來自子步驟的全部行。對這樣的父步驟，直到全部行從子步驟返回以前 Oracle不能實現該父步驟。這樣的父步驟包括排序，排序一合併的鏈接，組功能和總計。對於這樣的操做，能夠用all_rows做爲優化目標，使該中類型的操做耗費的資源最少。
有時語句執行時，並非象上面說的那樣一步一步有先有後的進行，而是可能並行運行，如在實際環境中，三、五、4步可能並行運行，以便取得更好的效率。從上面的樹型圖上，是很難看出各個操做執行的前後順序，而經過ORACLE生成的另外一種形式的執行計劃，則能夠很容易的看出哪一個操做先執行，哪一個後執行，這樣的執行計劃是咱們真正須要的，後面會給出詳細說明。如今先來看一些預備知識。
|
優化器在造成執行計劃時須要作的一個重要選擇是如何從數據庫查詢出須要的數據。對於SQL語句存取的任何表中的任何行，可能存在許多存取路徑(存取方法)，經過它們能夠定位和查詢出須要的數據。優化器選擇其中自認爲是最優化的路徑。在物理層，oracle讀取數據，一次讀取的最小單位爲數據庫塊(由多個連續的操做系統塊組成)，一次讀取的最大值由操做系統一次I/O的最大值與multiblock參數共同決定，因此即便只須要一行數據，也是將該行所在的數據庫塊讀入內存。邏輯上，oracle用以下存取方法訪問數據：
全表掃描
經過ROWID的表存取（Table Access by ROWID或rowid lookup）
行的ROWID指出了該行所在的數據文件、數據塊以及行在該塊中的位置，因此經過ROWID來存取數據能夠快速定位到目標數據上，是Oracle存取單行數據的最快方法。爲經過ROWID存取表，Oracle 首先要獲取被選擇行的ROWID，或從語句的WHERE子句中獲得，或者經過表的一個或多個索引的索引掃描獲得。Oracle而後以獲得的ROWID爲依據定位每一個被選擇的行。此存取方法不會用到多塊讀操做，一次I/O只能讀取一個數據塊。咱們常常在執行計劃中看到該存取方法，如經過索引查詢數據。使用ROWID存取的方法：
在惟一索引列上使用了range操做符(> < <> >= <= between)
在組合索引上，只使用部分列進行查詢，致使查詢出多行
索引全掃描(index full scan)
row source(表)之間的鏈接順序對於查詢的效率有很是大的影響。經過首先存取特定的表，即將該表做爲驅動表，這樣能夠先應用某些限制條件，從而獲得一個較小的row source，使鏈接的效率較高，這也就是咱們常說的要先執行限制條件的緣由。通常是在將表讀入內存時，應用where子句中對該表的限制條件。
根據2個row source的鏈接條件的中操做符的不一樣，能夠將鏈接分爲等值鏈接(如WHERE A.COL3 = B.COL4)、非等值鏈接(WHERE A.COL3 > B.COL4)、外鏈接(WHERE A.COL3 = B.COL4(+))。下面以等值鏈接爲例進行介紹。在後面的介紹中，都已：
鏈接類型：
排序 - - 合併鏈接(Sort Merge Join (SMJ) )
!8431bb36e2fa4647aa490996eeaee021.jpg!若是row source已經在鏈接關聯列上被排序，則該鏈接操做就不須要再進行sort操做，這樣能夠大大提升這種鏈接操做的鏈接速度，由於排序是個極其費資源的操做， 特別是對於較大的表。 預先排序的row source包括已經被索引的列(如a.col3或b.col4上有索引)或row source已經在前面的步驟中被排序了。儘管合併兩個row source的過程是串行的，可是能夠並行訪問這兩個row source(如並行讀入數據，並行排序).排序是一個費時、費資源的操做，特別對於大表。基於這個緣由，SMJ常常不是一個特別有效的鏈接方法，可是若是2個row source都已經預先排序，則這種鏈接方法的效率較高。
SMJ鏈接的例子：
SQL> explain plan for
select /*+ ordered */ e.deptno, d.deptno
from emp e, dept d
where e.deptno = d.deptno
order by e.deptno, d.deptno;
Query Plan
-------------------------------------
SELECT STATEMENT [CHOOSE] Cost=17
MERGE JOIN
SORT JOIN
TABLE ACCESS FULL EMP [ANALYZED]
SORT JOIN
TABLE ACCESS FULL DEPT [ANALYZED]
嵌套循環(Nested Loops (NL) )
NL鏈接的例子：
SQL> explain plan for
select a.dname, b.sql
from dept a, emp b
where a.deptno = b.deptno;
Query Plan
-------------------------
SELECT STATEMENT [CHOOSE] Cost=5
NESTED LOOPS
TABLE ACCESS FULL DEPT [ANALYZED]
TABLE ACCESS FULL EMP [ANALYZED]
哈希鏈接 (Hash Join, HJ)
理論上來講比NL與SMJ更高效，並且只用在CBO優化器中。較小的row source被用來構建hash table與bitmap，第2個row source被用來被hansed，並與第一個row source生成的hash table進行匹配，以便進行進一步的鏈接。Bitmap被用來做爲一種比較快的查找方法，來檢查在hash table中是否有匹配的行。特別的，當hash table比較大而不能所有容納在內存中時，這種查找方法更爲有用。這種鏈接方法也有NL鏈接中所謂的驅動表的概念，被構建爲hash table與bitmap的表爲驅動表，當被構建的hash table與bitmap能被容納在內存中時，這種鏈接方式的效率極高。要使哈希鏈接有效，須要設置HASH_JOIN_ENABLED=TRUE，缺省狀況下該參數爲TRUE，另外，不要忘了還要設置hash_area_size參數，以使哈希鏈接高效運行，由於哈希鏈接會在該參數指定大小的內存中運行，太小的參數會使哈希鏈接的性能比其餘鏈接方式還要低。
HASH鏈接的例子：
SQL> explain plan for
select /*+ use_hash(emp) */ empno
from emp, dept
where emp.deptno = dept.deptno;
Query Plan
----------------------------
SELECT STATEMENT [CHOOSE] Cost=3
HASH JOIN
TABLE ACCESS FULL DEPT
TABLE ACCESS FULL EMP
笛卡兒乘積(Cartesian Product)
當兩個row source作鏈接，可是它們之間沒有關聯條件時，就會在兩個row source中作笛卡兒乘積，這一般由編寫代碼疏漏形成(即程序員忘了寫關聯條件)。笛卡爾乘積是一個表的每一行依次與另外一個表中的全部行匹配。在特殊狀況下咱們可使用笛卡兒乘積，如在星形鏈接中，除此以外，咱們要儘可能避免使用笛卡兒乘積。注意在下面的語句中，在2個表之間沒有鏈接。
在哪一種狀況下用哪一種鏈接方法比較好：
1.排序 - - 合併鏈接(Sort Merge Join, SMJ)：
須要注意的是，以上方法並不會真正執行sql，只是產生執行計劃。
例1：
假設LARGE_TABLE是一個較大的表，且username列上沒有索引，則運行下面的語句：
SQL> SELECT * FROM LARGE_TABLE where USERNAME = ‘TEST’;
Query Plan -----------------------------------------
SELECT STATEMENT Optimizer=CHOOSE (Cost=1234 Card=1 Bytes=14)
TABLE ACCESS FULL LARGE_TABLE [:Q65001] [ANALYZED]
在這個例子中，TABLE ACCESS FULL LARGE_TABLE是第一個操做，意思是在LARGE_TABLE表上作全表掃描。當這個操做完成以後，產生的row source中的數據被送往下一步驟進行處理，在此例中，SELECT STATEMENT 操做是這個查詢語句的最後一步。Optimizer=CHOOSE 指明這個查詢的optimizer_mode，即optimizer_mode 初始化參數指定的值，它並非指語句執行時真的使用了該優化器。決定該語句使用何種優化器的惟一方法是看後面的cost部分。若是給出的是下面的形式，則代表使用的是CBO優化器，此處的cost表示優化器認爲該執行計劃的代價:
SELECT STATEMENT Optimizer=CHOOSE (Cost=1234 Card=1 Bytes=14) 假如執行計劃中給出的是相似下面的信息，則代表是使用RBO優化器，由於cost部分的值爲空，或者壓根就沒有cost部分。
例2：
假定A、B、C都是否是小表，且在A表上一個組合索引：A(a.col1,a.col2) ，注意a.col1列爲索引的引導列。
select A.col4
from A , B , C
where B.col3 = 10 and A.col1 = B.col1 and A.col2 = C.col2 and C.col3 = 5
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 MERGE JOIN
2 1 SORT (JOIN)
3 2 NESTED LOOPS
4 3 TABLE ACCESS (FULL) OF 'B'
5 3 TABLE ACCESS (BY INDEX ROWID) OF 'A'
6 5 INDEX (RANGE SCAN) OF 'INX_COL12A' (NON-UNIQUE)
7 1 SORT (JOIN)
8 7 TABLE ACCESS (FULL) OF 'C'
Statistics
----------------------------------------------------------
0 recursive calls
8 db block gets
6 consistent gets
0 physical reads
34
0 redo size
551 bytes sent via SQL*Net to client
430 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
6 rows processed
在表作鏈接時，只能2個表先作鏈接，而後將鏈接後的結果做爲一個row source，與剩下的表作鏈接，在上面的例子中，鏈接順序爲B與A先鏈接，而後再與C鏈接：
B <---> A <---> C
col3=10 col3=5若是沒有執行計劃，分析一下，上面的3個表應該拿哪個做爲第一個驅動表？從SQL語句看來，只有B表與C表上有限制條件，因此第一個驅動表應該爲這2個表中的一個，究竟是哪個呢？B表有謂詞B.col3 = 10，這樣在對B表作全表掃描的時候就將where子句中的限制條件(B.col3 = 10)用上，從而獲得一個較小的row source, 因此B表應該做爲第一個驅動表。並且這樣的話，若是再與A表作關聯，能夠有效利用A表的索引(由於A表的col1列爲leading column)。固然上面的查詢中C表上也有謂詞(C.col3 = 5)，有人可能認爲C表做爲第一個驅動表也能得到較好的性能。讓咱們再來分析一下：若是C表做爲第一個驅動表，則能保證驅動表生成很小的row source，可是看看鏈接條件A.col2 = C.col2，此時就沒有機會利用A表的索引，由於A表的col2列不爲leading column，這樣nested loop的效率不好，從而致使查詢的效率不好。因此對於NL鏈接選擇正確的驅動表很重要。 基於以上原則：上面查詢比較好的鏈接順序爲(B - - > A) - - > C。若是數據庫是基於代價的優化器，它會利用計算出的代價來決定合適的驅動表與合適的鏈接順序。通常來講，CBO都會選擇正確的鏈接順序，若是CBO選擇了比較差的鏈接順序，咱們還可使用ORACLE提供的hints來讓CBO採用正確的鏈接順序。以下所示：
在執行計劃中，須要知道哪一個操做是先執行的，哪一個操做是後執行的，這對於判斷哪一個表爲驅動表有用處。判斷以前，若是對錶的訪問是經過rowid，且該rowid的值是從索引掃描中來得，則將該索引掃描先從執行計劃中暫時去掉。而後在執行計劃剩下的部分中，判斷執行順序的指導原則就是：最右、最上的操做先執行。具體解釋以下：
獲得去除妨礙判斷的索引掃描後的執行計劃：
談論上下關係時，只對連續的、縮進一致的行有效。
從這個圖中咱們能夠看到，對於NESTED LOOPS部分，最右、最上的操做是TABLE ACCESS (FULL) OF 'B'，因此這一操做先執行，因此該操做對應的B表爲第一個驅動表(外部表)，天然，A表就爲內部表了。從圖中還能夠看出，B與A表作嵌套循環後生成了新的row source ，對該row source進行來排序後，與C表對應的排序了的row source(應用了C.col3 = 5限制條件)進行MSJ鏈接操做。因此從上面能夠得出以下事實：B表先與A表作嵌套循環，而後將生成的row source與C表作排序—合併鏈接。
經過分析上面的執行計劃，咱們不能說C表必定在B、A表以後才被讀取，事實上，B表有可能與C表同時被讀入內存，由於將表中的數據讀入內存的操做可能爲並行的。事實上許多操做可能爲交叉進行的，由於ORACLE讀取數據時，若是就是須要一行數據也是將該行所在的整個數據塊讀入內存，並且還有可能爲多塊讀。
看執行計劃時，咱們的關鍵不是看哪一個操做先執行，哪一個操做後執行，而是關鍵看錶之間鏈接的順序(如得知哪一個爲驅動表，這須要從操做的順序進行判斷)、使用了何種類型的關聯及具體的存取路徑(如判斷是否利用了索引) 在從執行計劃中判斷出哪一個表爲驅動表後，根據咱們的知識判斷該表做爲驅動表(就像上面判斷ABC表那樣)是否合適，若是不合適，對SQL語句進行更改，使優化器能夠選擇正確的驅動表。
基於代價的優化器在絕大多數狀況下它會選擇正確的優化器，減輕了DBA的負擔。但有時它也聰明反被聰明誤，選擇了不好的執行計劃，使某個語句的執行變得奇慢無比。此時就須要DBA進行人爲的干預，告訴優化器使用咱們指定的存取路徑或鏈接類型生成執行計劃，從而使語句高效的運行。例如: 對於一個特定的語句，執行全表掃描要比執行索引掃描更有效，則咱們能夠指示優化器使用全表掃描。在ORACLE中，是經過爲語句添加hints(提示)來實現干預優化器優化的目的。
hints是oracle提供的一種機制，用來告訴優化器按照咱們的告訴它的方式生成執行計劃。能夠用hints來實現：
SQL優化的通常性原則
目標：
- 減小服務器資源消耗（主要是磁盤IO）；
設計方面：
- 儘可能依賴oracle的優化器，併爲其提供條件；
- 合適的索引，索引的雙重效應，列的選擇性；
編碼方面：
- 利用索引，避免大表FULL TABLE SCAN；
- 合理使用臨時表；
- 避免寫過於複雜的sql，不必定非要一個sql解決問題；
- 在不影響業務的前提下減少事務的粒度；
優化歸納
- 建立表的時候。應儘可能創建主鍵，儘可能根據實際須要調整數據表的PCTFREE和PCTUSED參數；大數據表刪除，用truncate table代替delete。
- 合理使用索引，在OLTP應用中一張表的索引不要太多。數據重複量大的列不要創建二叉樹索引，能夠採用位圖索引；組合索引的列順序儘可能與查詢條件列順序保持一致；對於數據操做頻繁的表，索引須要按期重建，以減小失效的索引和碎片。
- 查詢儘可能用肯定的列名，少用*號。select count(key)from tab where key> 0性能優於select count(*)from tab；
- 儘可能少嵌套子查詢，這種查詢會消耗大量的CPU資源；對於有比較多or運算的查詢，建議分紅多個查詢，用union all聯結起來；多表查詢的查詢語句中，選擇最有效率的表名順序。Oracle解析器對錶解析從右到左，因此記錄少的表放在右邊。
- 儘可能多用commit語句提交事務，能夠及時釋放資源、解鎖、釋放日誌空間、減小管理花費；在頻繁的、性能要求比較高的數據操做中，儘可能避免遠程訪問，如數據庫鏈等，訪問頻繁的表能夠常駐內存：alter table．．．cache；
隨着數據庫中數據的增長，系統的響應速度就成爲目前系統須要解決的最主要的問題之一。系統優化中一個很重要的方面就是SQL語句的優化。對於大量數據，劣質SQL語句和優質SQL語句之間的速度差異能夠達到上百倍，對於一個系統不是簡單地能實現其功能就可，而是要寫出高質量的SQL語句，提升系統的可用性。在多數狀況下，Oracle使用索引來更快地遍歷表，優化器主要根據定義的索引來提升性能。若是在SQL語句的where子句中寫的SQL代碼不合理，就會形成優化器刪去索引而使用全表掃描，通常就這種SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時咱們應清楚優化器根據何種原則來使用索引，這有助於寫出高性能的SQL語句。SQL語句的編寫原則和SQL語句的優化，請跟我一塊兒學習如下幾方面：
- 避免複雜的多表關聯
select …
from user_files uf, df_money_files dm,
cw_charge_record cc
where
uf.user_no = dm.user_no
and dm.user_no = cc.user_no
and ……
and not exists(select …)
很難優化，隨着數據量的增長性能的風險很大。
- 避免使用 '* '
當你想在SELECT子句中列出全部的COLUMN時,使用動態SQL列引用 ‘*’ 是一個方便的方法。不幸的是,這是一個常低效的方法。實際上,ORACLE在解析的過程當中，會將’*’ 依次轉換成全部的列名，這個工做是經過查詢數據字典完成的， 這意味着將耗費更多的時間；只提取你所要使用的列，使用別名可以加快解析速度；
- 避免使用耗費資源的操做
帶有DISTINCT，UNION，MINUS，INTERSECT，ORDER BY的SQL語句會啓動SQL引擎執行耗費資源的排序(SORT)功能。DISTINCT須要一次排序操做， 而其餘的至少須要執行兩次排序。
一般, 帶有UNION， MINUS， INTERSECT的SQL語句均可以用其餘方式重寫。
- 用EXISTS替換DISTINCT
例如:
低效:
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);
- 用UNION-ALL 替換UNION ( if possible)
當SQL語句須要UNION兩個查詢結果集合時,這兩個結果集合會以UNION-ALL的方式被合併, 而後在輸出最終結果前進行排序.
舉例:
低效：
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95’
UNION
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95’
高效:
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95’
UNION ALL
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95’
- 自動選擇索引
若是表中有兩個以上（包括兩個）索引，其中有一個惟一性索引，而其餘是非惟一性在這種狀況下，ORACLE將使用惟一性索引而徹底忽略非惟一性索引．
舉例:
SELECT ENAME
FROM EMP
WHERE EMPNO = 2326
AND DEPTNO = 20 ;
這裏，只有EMPNO上的索引是惟一性的，因此EMPNO索引將用來檢索記錄．
TABLE ACCESS BY ROWID ON EMP
INDEX UNIQUE SCAN ON EMP_NO_IDX
- 至少要包含組合索引的第一列
若是索引是創建在多個列上， 只有在它的第一個列(leading column)被where子句引用時，優化器纔會選擇使用該索引。
SQL> create table multiindexusage ( inda number , indb number , descr varchar2(10));
Table created.
SQL> create index multindex on multiindexusage(inda,indb);
Index created.
SQL> set autotrace traceonly
SQL> select * from multiindexusage where inda = 1;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'MULTIINDEXUSAGE'
2 1 INDEX (RANGE SCAN) OF 'MULTINDEX' (NON-UNIQUE)
SQL> select * from multiindexusage where indb = 1;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'MULTIINDEXUSAGE'
很明顯，當僅引用索引的第二個列時，優化器使用了全表掃描而忽略了索引。
- 避免在索引列上使用函數
WHERE子句中，若是索引列是函數的一部分。優化器將不使用索引而使用全表掃描。
舉例:
低效：
SELECT …
FROM DEPT
WHERE SAL * 12 > 25000;
高效:
SELECT …
FROM DEPT
WHERE SAL > 25000/12;
- 避免使用前置通配符
WHERE子句中， 若是索引列所對應的值的第一個字符由通配符(WILDCARD)開始， 索引將不被採用。
SELECT USER_NO,USER_NAME,ADDRESS
FROM USER_FILES
WHERE USER_NO LIKE '%109204421';
在這種狀況下，ORACLE將使用全表掃描。
- 避免在索引列上使用NOT
一般，咱們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響. 當ORACLE」遇到」NOT,他就會中止使用索引轉而執行全表掃描.
舉例:
低效: (這裏,不使用索引)
SELECT …
FROM DEPT
WHERE DEPT_CODE <> 0;
高效: (這裏,使用了索引)
SELECT …
FROM DEPT
WHERE DEPT_CODE > 0;
- 避免在索引列上使用 IS NULL和IS NOT NULL
避免在索引中使用任何能夠爲空的列，ORACLE將沒法使用該索引 ．對於單列索引，若是列包含空值，索引中將不存在此記錄. 對於複合索引，若是每一個列都爲空，索引中一樣不存在此記錄. 若是至少有一個列不爲空，則記錄存在於索引中．
若是惟一性索引創建在表的A列和B列上, 而且表中存在一條記錄的A,B值爲(123,null) , ORACLE將不接受下一條具備相同A,B值（123,null）的記錄(插入). 然而若是全部的索引列都爲空，ORACLE將認爲整個鍵值爲空而空不等於空. 所以你能夠插入1000條具備相同鍵值的記錄,固然它們都是空!
由於空值不存在於索引列中,因此WHERE子句中對索引列進行空值比較將使ORACLE停用該索引.
任何在where子句中使用is null或is not null的語句優化器是不容許使用索引的。
- 避免出現索引列自動轉換
當比較不一樣數據類型的數據時, ORACLE自動對列進行簡單的類型轉換.
假設EMP_TYPE是一個字符類型的索引列.
SELECT USER_NO,USER_NAME,ADDRESS
FROM USER_FILES
WHERE USER_NO = 109204421
這個語句被ORACLE轉換爲:
SELECT USER_NO,USER_NAME,ADDRESS
FROM USER_FILES
WHERE TO_NUMBER(USER_NO) = 109204421
由於內部發生的類型轉換, 這個索引將不會被用到!
- 在查詢時儘可能少用格式轉換
如用 WHERE a.order_no = b.order_no不用WHERE TO_NUMBER (substr(a.order_no, instr(b.order_no, '.') - 1)
- 減小訪問數據庫的次數
當執行每條SQL語句時， ORACLE在內部執行了許多工做，解析SQL語句，估算索引的利用率，綁定變量，讀數據塊等等。因而可知，減小訪問數據庫的次數 , 就能實際上減小ORACLE的工做量。
- 使用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%’;
- 減小對錶的查詢
在含有子查詢的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)
- WHERE子句中的鏈接順序
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理, 當在WHERE子句中有多個表聯接時，WHERE子句中排在最後的表應當是返回行數可能最少的表，有過濾條件的子句應放在WHERE子句中的最後。
如：設從emp表查到的數據比較少或該表的過濾條件比較肯定，能大大縮小查詢範圍，則將最具備選擇性部分放在WHERE子句中的最後：
select * from emp e,dept d
where d.deptno >10 and e.deptno =30 ;
若是dept表返回的記錄數較多的話，上面的查詢語句會比下面的查詢語句響應快得多。
select * from emp e,dept d
where e.deptno = 30 and d.deptno >10 ;
最好不要在WHERE子句中使用函或表達式，若是要使用的話，最好統一使用相同的表達式或函數，這樣便於之後使用合理的索引。
- Order by語句
ORDER BY語句決定了Oracle如何將返回的查詢結果排序。Order by語句對要排序的列沒有什麼特別的限制，也能夠將函數加入列中（象聯接或者附加等）。任何在Order by語句的非索引項或者有計算表達式都將下降查詢速度。仔細檢查order by語句以找出非索引項或者表達式，它們會下降性能。解決這個問題的辦法就是重寫order by語句以使用索引，也能夠爲所使用的列創建另一個索引，同時應絕對避免在order by子句中使用表達式。
- 聯接列
對於有聯接的列，即便最後的聯接值爲一個靜態值，優化器是不會使用索引的。
select * from employss
where
first_name||''||last_name ='Beill Cliton';
系統優化器對基於last_name建立的索引沒有使用。
當採用下面這種SQL語句的編寫，Oracle系統就能夠採用基於last_name建立的索引。
select * from employee
where
first_name ='Beill' and last_name ='Cliton';
- 帶通配符（%）的like語句 *
通配符（%）在搜尋詞首出現，Oracle系統不使用last_name的索引。
select * from employee where last_name like '%cliton%';
在不少狀況下可能沒法避免這種狀況，可是必定要心中有底，通配符如此使用會下降查詢速度。然而當通配符出如今字符串其餘位置時，優化器就能利用索引。在下面的查詢中索引獲得了使用：
select * from employee where last_name like 'c%';
- 用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
順序
WHERE > GROUP > HAVING
- 用NOT EXISTS 替代 NOT IN
在子查詢中,NOT IN子句將執行一個內部的排序和合並. 不管在哪一種狀況下,NOT IN都是最低效的 (由於它對子查詢中的表執行了一個全表遍歷)。
使用NOT EXISTS 子句能夠有效地利用索引。儘量使用NOT EXISTS來代替NOT IN，儘管兩者都使用了NOT（不能使用索引而下降速度），NOT EXISTS要比NOT IN查詢效率更高。
例如:
deptno NOT IN (SELECT deptno FROM emp);
NOT EXISTS
(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno);
2要比1的執行性能好不少。
由於1中對emp進行了full table scan,這是很浪費時間的操做。並且1中沒有用到emp的index， 由於沒有where子句。而2中的語句對emp進行的是縮小範圍的查詢。
- *用索引提升效率
索引是表的一個概念部分,用來提升檢索數據的效率，ORACLE使用了一個複雜的自平衡B-tree結構. 一般,經過索引查詢數據比全表掃描要快. 當ORACLE找出執行查詢和Update語句的最佳路徑時,ORACLE優化器將使用索引. 一樣在聯結多個表時使用索引也能夠提升效率. 另外一個使用索引的好處是,它提供了主鍵(primary key)的惟一性驗證。
一般, 在大型表中使用索引特別有效. 固然,你也會發現, 在掃描小表時,使用索引一樣能提升效率. 雖然使用索引能獲得查詢效率的提升,可是咱們也必須注意到它的代價. 索引須要空間來存儲,也須要按期維護, 每當有記錄在表中增減或索引列被修改時, 索引自己也會被修改. 這意味着每條記錄的INSERT , DELETE , UPDATE將爲此多付出4 , 5 次的磁盤I/O . 由於索引須要額外的存儲空間和處理,那些沒必要要的索引反而會使查詢反應時間變慢.。按期的重構索引是有必要的。
- 避免在索引列上使用計算
WHERE子句中，若是索引列是函數的一部分．優化器將不
使用索引而使用全表掃描．
低效：
SELECT … FROM DEPT WHERE SAL * 12 > 25000;
高效:
SELECT … FROM DEPT WHERE SAL > 25000/12;
- 用>= 替代 >
若是DEPTNO上有一個索引。
高效:
SELECT *
FROM EMP
WHERE DEPTNO >=4
低效:
SELECT *
FROM EMP
WHERE DEPTNO >3
- 經過使用>=、<=等，避免使用NOT命令
例子：
雖然這兩種查詢的結果同樣，可是第二種查詢方案會比第一種查詢方案更快些。第二種查詢容許Oracle對salary列使用索引，而第一種查詢則不能使用索引。
- 若是有其它辦法，不要使用子查詢
- 外部聯接"+"的用法
外部聯接"+"按其在"="的左邊或右邊分左聯接和右聯接。若不帶"+"運算符的表中的一個行不直接匹配於帶"+"預算符的表中的任何行，則前者的行與後者中的一個空行相匹配並被返回。利用外部聯接"+"，能夠替代效率十分低下的 not in 運算，大大提升運行速度。例如，下面這條命令執行起來很慢：
- 儘可能多使用COMMIT
事務是消耗資源的，大事務還容易引發死鎖
COMMIT所釋放的資源:
- 回滾段上用於恢復數據的信息.
- 被程序語句得到的鎖
- redo log buffer 中的空間
- ORACLE爲管理上述3種資源中的內部花費
- 用TRUNCATE替代DELETE
當刪除表中的記錄時,在一般狀況下, 回滾段(rollback segments ) 用來存放能夠被恢復的信息. 若是你沒有COMMIT事務,ORACLE會將數據恢復到刪除以前的狀態(準確地說是恢復到執行刪除命令以前的情況)
而當運用TRUNCATE時, 回滾段再也不存聽任何可被恢復的信息.當命令運行後,數據不能被恢復.所以不多的資源被調用,執行時間也會很短。
- 計算記錄條數
和通常的觀點相反, count(*比count(1)稍快 , 固然若是能夠經過索引檢索,對索引列的計數仍舊是最快的。
例如 COUNT(EMPNO)
- 字符型字段的引號
好比有的表PHONE_NO字段是CHAR型,並且建立有索引，
但在WHERE條件中忘記了加引號，就不會用到索引。
WHERE PHONE_NO=‘13920202022’
WHERE PHONE_NO=13920202022
- 1. oracle 性能優化
- 2. oracle性能優化
- 3. Oracle性能優化
- 4. Oracle SQL性能優化 SQL優化
- 5. oracle 性能優化 06_sql優化
- 6. Oracle SQL性能優化
- 7. ORACLE性能優化:內存
- 8. Oracle性能優化有感
- 9. Oracle性能優化--DBMS_PROFILER
- 10. Oracle update性能優化
- 更多相關文章...
- • SEO - 搜索引擎優化 - 網站建設指南
- • MySQL的優勢（優點） - MySQL教程
- • 算法總結-廣度優先算法
- • JDK13 GA發佈：5大特性解讀
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. oracle 性能優化
- 2. oracle性能優化
- 3. Oracle性能優化
- 4. Oracle SQL性能優化 SQL優化
- 5. oracle 性能優化 06_sql優化
- 6. Oracle SQL性能優化
- 7. ORACLE性能優化:內存
- 8. Oracle性能優化有感
- 9. Oracle性能優化--DBMS_PROFILER
- 10. Oracle update性能優化