SQL共享原理
ORACLE將執行過的SQL語句存放在內存的共享池(shared buffer pool)中，可以被所有的數據庫用戶共享。當你執行一個SQL語句(有時被稱為一個游標)時,如果它和之前的執行過的語句完全相同,ORACLE就能很快獲得已經被解析的語句以及最好的 執行路徑. 這個功能大大地提高了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 = 32013484095139
硬解析即整個SQL語句的執行需要完完全全的解析，生成執行計划。而硬解析，生成執行計划需要耗用CPU資源，以及SGA資源。在此不得不提的是對庫緩存中閂的使用。閂是鎖的細化，可以理解為是一種輕量級的串行化設備。當進程申請到閂后，則這些閂用於保護共享內存的數在同一時刻不會被兩個以上的進程修改。在硬解析時，需要申請閂的使用，而閂的數量在有限的情況下需要等待。大量的閂的使用由此造成需要使用閂的進程排隊越頻繁，性能則逾低下。
綁定變量解決硬解析問題
未使用綁定變量的語句
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首先實現上圖樹結構圖形里作為葉子出現的那些步驟(例如步驟3、5、6)。由每一步返回的行稱為它下一步驟的行源。然后Oracle實現父步驟。 Oracle以下列順序實現這些步驟：
1、Oracle實現步驟５，並將結果ROWID返回給第４步。
對於以上的操作過程，可以使用first_rows作為優化目標以便於實現快速響應用戶的請求。有些父步驟在它們被實現之前需要來自子步驟的所有行。對這樣的父步驟，直到所有行從子步驟返回之前 Oracle不能實現該父步驟。這樣的父步驟包括排序，排序一合並的連接，組功能和總計。對於這樣的操作，可以用all_rows作為優化目標，使該中類型的操作耗費的資源最少。
有時語句執行時，並不是象上面說的那樣一步一步有先有后的進行，而是可能並行運行，如在實際環境中，3、5、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