很久不來了,最近忙于Oracle數據庫大數據量的業務邏輯處理,整理一些零散的網上資料.項目忙完后再結合自己經驗,給出文章.
申明:
下面內容來自
http://www.delphibbs.com/keylife/iblog_show.asp?xid=9256
1.合理使用索引
索引是數據庫中重要的數據結構，它的根本目的就是為了提高查詢效率。現在大多數的數據庫產品都采用IBM最先提出的ISAM索引結構。索引的使用要恰到好處，其使用原則如下：
●在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的字段則由優化器自動生成索引。
●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引。
●在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的“性別”列上只有“男”與“女”兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。
●如果待排序的列有多個，可以在這些列上建立復合索引（compound index）。
●使用系統工具。如Informix數據庫有一個tbcheck工具，可以在可疑的索引上進行檢查。在一些數據庫服務器上，索引可能失效或者因為頻繁操作而使得讀取效率降低，如果一個使用索引的查詢不明不白地慢下來，可以試著用tbcheck工具檢查索引的完整性，必要時進行修復。另外，當數據庫表更新大量數據后，刪除并重建索引可以提高查詢速度。
(1)在下面兩條select語句中:
select * from table1 where field1<=10000 and field1>=0;
select * from table1 where field1>=0 and field1<=10000;
如果數據表中的數據field1都>=0,則第一條select語句要比第二條select語句效率高的多，因為第二條select語句的第一個條件耗費了大量的系統資源。
第一個原則：在where子句中應把最具限制性的條件放在最前面。
(2)在下面的select語句中:
select * from tab where a=… and b=… and c=…;
若有索引index(a,b,c)，則where子句中字段的順序應和索引中字段順序一致。
第二個原則：where子句中字段的順序應和索引中字段順序一致。
以下假設在field1上有唯一索引I1，在field2上有非唯一索引I2。
(3) select field3,field4 from tb where field1='sdf' 快
select * from tb where field1='sdf' 慢，
因為后者在索引掃描后要多一步ROWID表訪問。
(4) select field3,field4 from tb where field1>='sdf' 快
select field3,field4 from tb where field1>'sdf' 慢
因為前者可以迅速定位索引。
(5) select field3,field4 from tb where field2 like 'R%' 快
select field3,field4 from tb where field2 like '%R' 慢，
因為后者不使用索引。
(6) 使用函數如：
select field3,field4 from tb where upper(field2)='RMN'不使用索引。
如果一個表有兩萬條記錄，建議不使用函數；如果一個表有五萬條以上記錄，嚴格禁止使用函數！兩萬條記錄以下沒有限制。
(7) 空值不在索引中存儲，所以
select field3,field4 from tb where field2 is[not] null不使用索引。
(8) 不等式如
select field3,field4 from tb where field2!='TOM'不使用索引。
相似地，
select field3,field4 from tb where field2 not in('M','P')不使用索引。
(9) 多列索引，只有當查詢中索引首列被用于條件時，索引才能被使用。
(10) MAX，MIN等函數，如
Select max(field2) from tb使用索引。所以，如果需要對字段取max，min，sum等，應該加索引。
一次只使用一個聚集函數，如：
select “min”=min(field1), “max”=max(field1) from tb
不如：select “min”=(select min(field1) from tb) , “max”=(select max(field1) from tb)
(11) 重復值過多的索引不會被查詢優化器使用。而且因為建了索引，修改該字段值時還要修改索引，所以更新該字段的操作比沒有索引更慢。
(12) 索引值過大（如在一個char(40)的字段上建索引），會造成大量的I/O開銷（甚至會超過表掃描的I/O開銷）。因此，盡量使用整數索引。 Sp_estspace可以計算表和索引的開銷。
(13) 對于多列索引，order by的順序必須和索引的字段順序一致。
(14) 在sybase中，如果order by的字段組成一個簇索引，那么無須做order by。記錄的排列順序是與簇索引一致的。
(15) 多表聯結（具體查詢方案需要通過測試得到）
where子句中限定條件盡量使用相關聯的字段，且盡量把相關聯的字段放在前面。
select a.field1,b.field2 from a,b where a.field3=b.field3
1. field3上沒有索引的情況下:
對a作全表掃描，結果排序
對b作全表掃描，結果排序
結果合并。
對于很小的表或巨大的表比較合適。
2. field3上有索引
按照表聯結的次序，b為驅動表，a為被驅動表
對b作全表掃描
對a作索引范圍掃描
如果匹配，通過a的rowid訪問
(16) 避免一對多的join。如：
select tb1.field3,tb1.field4,tb2.field2 from tb1,tb2 where tb1.field2=tb2.field2 and tb1.field2=‘BU1032’ and tb2.field2= ‘aaa’
不如：
declare @a varchar(80)
select @a=field2 from tb2 where field2=‘aaa’
select tb1.field3,tb1.field4,@a from tb1 where field2= ‘aaa’
(16) 子查詢
用exists/not exists代替in/not in操作
比較：
select a.field1 from a where a.field2 in(select b.field1 from b where b.field2=100)
select a.field1 from a where exists( select 1 from b where a.field2=b.field1 and b.field2=100)
select field1 from a where field1 not in( select field2 from b)
select field1 from a where not exists( select 1 from b where b.field2=a.field1)
(17) 主、外鍵主要用于數據約束，sybase中創建主鍵時會自動創建索引，外鍵與索引無關，提高性能必須再建索引。
(18) char類型的字段不建索引比int類型的字段不建索引更糟糕。建索引后性能只稍差一點。
(19) 使用count(*)而不要使用count(column_name)，避免使用count(distinct column_name)。
(20) 等號右邊盡量不要使用字段名，如：
select * from tb where field1 = field3
(21) 避免使用or條件，因為or不使用索引。
2.避免使用order by和group by字句。
因為使用這兩個子句會占用大量的臨時空間(tempspace),如果一定要使用，可用視圖、人工生成臨時表的方法來代替。
如果必須使用，先檢查memory、tempdb的大小。
測試證明，特別要避免一個查詢里既使用join又使用group by，速度會非常慢！
3.盡量少用子查詢，特別是相關子查詢。因為這樣會導致效率下降。
一個列的標簽同時在主查詢和where子句中的查詢中出現，那么很可能當主查詢中的列值改變之后，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那么要在子查詢中過濾掉盡可能多的行。
4．消除對大型表行數據的順序存取
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如采用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那么這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（學號、課程號、成績）。如果兩個表要做連接，就要在“學號”這個連接字段上建立索引。
還可以使用并集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的集合，所以應該改為如下語句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
5．避免困難的正規表達式
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”
即使在zipcode字段上建立了索引，在這種情況下也還是采用順序掃描的方式。如果把語句改為SELECT ＊ FROM customer WHERE zipcode >“98000”，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：SELECT ＊ FROM customer WHERE zipcode[2，3] >“80”，在where子句中采用了非開始子串，因而這個語句也不會使用索引。
6．使用臨時表加速查詢
把表的一個子集進行排序并創建臨時表，有時能加速查詢。它有助于避免多重排序操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時文件中，并按客戶的名字進行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然后以下面的方式在臨時表中查詢：
SELECT ＊ FROM cust_with_balance
WHERE postcode>“98000”
臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁盤I/O，所以查詢工作量可以得到大幅減少。
注意：臨時表創建后不會反映主表的修改。在主表中數據頻繁修改的情況下，注意不要丟失數據。
7．用排序來取代非順序存取
非順序磁盤存取是最慢的操作，表現在磁盤存取臂的來回移動。SQL語句隱藏了這一情況，使得我們在寫應用程序時很容易寫出要求存取大量非順序頁的查詢。
有些時候，用數據庫的排序能力來替代非順序的存取能改進查詢。
下面一篇文章比較詳細,寫得很.
申明:來自
http://itexam.csai.cn/oracle/no0088.htm
通過分析SQL語句的執行計劃優化SQL
|
| 作者： 不詳 來源： ChinaITLab http://www.csai.cn 2006年03月08日 |
第5章 ORACLE的執行計劃
背景知識：
為了更好的進行下面的內容我們必須了解一些概念性的術語：
共享sql語句
為了不重復解析相同的SQL語句(因為解析操作比較費資源，會導致性能下降)，在第一次解析之后，ORACLE將SQL語句及解析后得到的執行計劃存放在內存中。這塊位于系統全局區域SGA(system global area)的共享池(shared buffer pool)中的內存可以被所有的數據庫用戶共享。因此，當你執行一個SQL語句(有時被稱為一個游標)時，如果該語句和之前的執行過的某一語句完全相同，并且之前執行的該語句與其執行計劃仍然在內存中存在，則ORACLE就不需要再進行分析，直接得到該語句的執行路徑。ORACLE的這個功能大大地提高了SQL的執行性能并大大節省了內存的使用。使用這個功能的關鍵是將執行過的語句盡可能放到內存中，所以這要求有大的共享池(通過設置shared buffer pool參數值)和盡可能的使用綁定變量的方法執行SQL語句。
當你向ORACLE 提交一個SQL語句，ORACLE會首先在共享內存中查找是否有相同的語句。這里需要注明的是，ORACLE對兩者采取的是一種嚴格匹配，要達成共享，SQL語句必須完全相同(包括空格,換行等)。
下面是判斷SQL語句是否與共享內存中某一SQL相同的步驟：
1) 對所發出語句的文本串進行hashed。如果hash值與已在共享池中SQL語句的hash值相同，則進行第2步；
2) 將所發出語句的文本串（包括大小寫、空白和注釋）與在第１步中識別的所有已存在的SQL語句相比較。
例如：
SELECT * FROM emp WHERE empno = 1000;
和下列每一個都不同
SELECT * from emp WHERE empno = 1000;
SELECT * FROM EMP WHERE empno = 1000;
SELECT * FROM emp WHERE empno = 2000;
在上面的語句中列值都是直接SQL語句中的，今后我們將這類sql成為硬編碼SQL或字面值SQL
使用綁定變量的SQL語句中必須使用相同的名字的綁定變量(bind variables) ，
例如：
a. 該2個sql語句被認為相同
select pin , name from people where pin = :blk1.pin;
select pin , name from people where pin = :blk1.pin;
b. 該2個sql語句被認為不相同
select pin , name from people where pin = :blk1.ot_ind;
select pin , name from people where pin = :blk1.ov_ind;
今后我們將上面的這類語句稱為綁定變量SQL。
3) 將所發出語句中涉及的對象與第２步中識別的已存在語句所涉及對象相比較。
例如:
如用戶user1與用戶user2下都有EMP表，則用戶user1發出的語句：SELECT * FROM EMP; 與
用戶user2發出的語句：SELECT * FROM EMP; 被認為是不相同的語句，因為兩個語句中引用的EMP不是指同一個表。
4) 在SQL語句中使用的捆綁變量的捆綁類型必須一致。
如果語句與當前在共享池中的另一個語句是等同的話，Oracle并不對它進行語法分析。而直接執行該語句，提高了執行效率，因為語法分析比較耗費資源。
注意的是，從oracle 8i開始，新引入了一個CURSOR_SHARING參數，該參數的主要目的就是為了解決在編程過程中已大量使用的硬編碼SQL問題。因為在實際開發中，很多程序人員為了提高開發速度，而采用類似下面的開發方法：
str_sql string;
int_empno int;
int_empno = 2000;
str_sql = ‘SELECT * FROM emp WHERE empno = ‘ + int_empno;
…………
int_empno = 1000;
str_sql = ‘SELECT * FROM emp WHERE empno = ‘ + int_empno;
上面的代碼實際上使用了硬編碼SQL，使我們不能使用共享SQL的功能，結果是數據庫效率不高。但是從上面的2個語句來看，產生的硬編碼SQL只是列值不同，其它部分都是相同的，如果僅僅因為列值不同而導致這2個語句不能共享是很可惜的，為了解決這個問題，引入了CURSOR_SHARING參數，使這類問題也可以使用共享SQL，從而使這樣的開發也可以利用共享SQL功能。聽起來不錯，ORACLE真為用戶著想，使用戶在不改變代碼的情況下還可以利用共享SQL的功能。真的如此嗎？天上不會無緣無故的掉一個餡餅的，ORACLE對該參數的使用做了說明，建議在經過實際測試后再改該參數的值(缺省情況下，該參數的值為EXACT，語句完全一致才使用共享SQL)。因為有可能該變該值后，你的硬編碼SQL是可以使用共享SQL了，但數據庫的性能反而會下降。 我在實際應用中已經遇到這種情況。所以建議編寫需要穩定運行程序的開發人員最好還是一開始就使用綁定變量的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。
Recursive SQL概念
有時為了執行用戶發出的一個sql語句，Oracle必須執行一些額外的語句，我們將這些額外的語句稱之為'recursive calls'或'recursive SQL statements'。如當一個DDL語句發出后，ORACLE總是隱含的發出一些recursive SQL語句，來修改數據字典信息，以便用戶可以成功的執行該DDL語句。當需要的數據字典信息沒有在共享內存中時，經常會發生Recursive calls，這些Recursive calls會將數據字典信息從硬盤讀入內存中。用戶不比關心這些recursive SQL語句的執行情況，在需要的時候，ORACLE會自動的在內部執行這些語句。當然DML語句與SELECT都可能引起recursive SQL。簡單的說，我們可以將觸發器視為recursive SQL。
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 );
此語句查詢薪水不在任何建議薪水范圍內的所有雇員的名字，工作，薪水和部門名。
訪問路徑(方法) -- access path
優化器在形成執行計劃時需要做的一個重要選擇是如何從數據庫查詢出需要的數據。對于SQL語句存取的任何表中的任何行，可能存在許多存取路徑(存取方法)，通過它們可以定位和查詢出需要的數據。優化器選擇其中自認為是最優化的路徑。
在物理層，oracle讀取數據，一次讀取的最小單位為數據庫塊(由多個連續的操作系統塊組成)，一次讀取的最大值由操作系統一次I/O的最大值與multiblock參數共同決定，所以即使只需要一行數據，也是將該行所在的數據庫塊讀入內存。邏輯上，oracle用如下存取方法訪問數據：
1) 全表掃描（Full Table Scans, FTS）
為實現全表掃描，Oracle讀取表中所有的行，并檢查每一行是否滿足語句的WHERE限制條件。Oracle順序地讀取分配給表的每個數據塊，直到讀到表的最高水線處(high water mark, HWM，標識表的最后一個數據塊)。一個多塊讀操作可以使一次I/O能讀取多塊數據塊(db_block_multiblock_read_count參數設定)，而不是只讀取一個數據塊，這極大的減少了I/O總次數，提高了系統的吞吐量，所以利用多塊讀的方法可以十分高效地實現全表掃描，而且只有在全表掃描的情況下才能使用多塊讀操作。在這種訪問模式下，每個數據塊只被讀一次。由于HWM標識最后一塊被讀入的數據，而delete操作不影響HWM值，所以一個表的所有數據被delete后，其全表掃描的時間不會有改善，一般我們需要使用truncate命令來使HWM值歸為0。幸運的是oracle 10G后，可以人工收縮HWM的值。
由FTS模式讀入的數據被放到高速緩存的Least Recently Used (LRU)列表的尾部，這樣可以使其快速交換出內存，從而不使內存重要的數據被交換出內存。使用FTS的前提條件：在較大的表上不建議使用全表掃描，除非取出數據的比較多，超過總量的5% -- 10%，或你想使用并行查詢功能時。
使用全表掃描的例子：
~~~~~~~~~~~~~~~~~~~~~~~~
SQL> explain plan for select * from dual;
Query Plan
-----------------------------------------
SELECT STATEMENT [CHOOSE] Cost=
TABLE ACCESS FULL DUAL
2) 通過ROWID的表存取（Table Access by ROWID或rowid lookup）
行的ROWID指出了該行所在的數據文件、數據塊以及行在該塊中的位置，所以通過ROWID來存取數據可以快速定位到目標數據上，是Oracle存取單行數據的最快方法。為了通過ROWID存取表，Oracle 首先要獲取被選擇行的ROWID，或者從語句的WHERE子句中得到，或者通過表的一個或多個索引的索引掃描得到。Oracle然后以得到的ROWID為依據定位每個被選擇的行。
這種存取方法不會用到多塊讀操作，一次I/O只能讀取一個數據塊。我們會經常在執行計劃中看到該存取方法，如通過索引查詢數據。
使用ROWID存取的方法：
SQL> explain plan for select * from dept where rowid = 'AAAAyGAADAAAAATAAF';
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID DEPT [ANALYZED]
3）索引掃描（Index Scan或index lookup）
我們先通過index查找到數據對應的rowid值(對于非唯一索引可能返回多個rowid值)，然后根據rowid直接從表中得到具體的數據，這種查找方式稱為索引掃描或索引查找(index lookup)。一個rowid唯一的表示一行數據，該行對應的數據塊是通過一次i/o得到的，在此情況下該次i/o只會讀取一個數據庫塊。
在索引中，除了存儲每個索引的值外，索引還存儲具有此值的行對應的ROWID值。索引掃描可以由2步組成：
(1) 掃描索引得到對應的rowid值。
(2) 通過找到的rowid從表中讀出具體的數據。每步都是單獨的一次I/O，但是對于索引，由于經常使用，絕大多數都已經CACHE到內存中，所以第1步的I/O經常是邏輯I/O，即數據可以從內存中得到。但是對于第2步來說，如果表比較大，則其數據不可能全在內存中，所以其I/O很有可能是物理I/O，這是一個機械操作，相對邏輯I/O來說，是極其費時間的。所以如果多大表進行索引掃描，取出的數據如果大于總量的5% -- 10%，使用索引掃描會效率下降很多。
如下列所示：
SQL> explain plan for select empno, ename from emp where empno=10;
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1
注意TABLE ACCESS BY ROWID EMP部分，這表明這不是通過FTS存取路徑訪問數據，而是通過rowid lookup存取路徑訪問數據的。在此例中，所需要的rowid是由于在索引查找empno列的值得到的，這種方式是INDEX UNIQUE SCAN查找，后面給予介紹，EMP_I1為使用的進行索引查找的索引名字。
但是如果查詢的數據能全在索引中找到，就可以避免進行第2步操作，避免了不必要的I/O，此時即使通過索引掃描取出的數據比較多，效率還是很高的，因為這只會在索引中讀取。所以上面我在介紹基于規則的優化器時，使用了select count(id) from SWD_BILLDETAIL where cn <'6'，而沒有使用select count(cn) from SWD_BILLDETAIL where cn <'6'。因為在實際情況中，只查詢被索引列的值的情況極為少，所以，如果我在查詢中使用count(cn)，則不具有代表性。
SQL> explain plan for select empno from emp where empno=10; -- 只查詢empno列值
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
INDEX UNIQUE SCAN EMP_I1
進一步講，如果sql語句中對索引列進行排序，因為索引已經預先排序好了，所以在執行計劃中不需要再對索引列進行排序
SQL> explain plan for select empno, ename from emp
where empno > 7876 order by empno;
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]
從這個例子中可以看到：因為索引是已經排序了的，所以將按照索引的順序查詢出符合條件的行，因此避免了進一步排序操作。
根據索引的類型與where限制條件的不同，有4種類型的索引掃描：
索引唯一掃描(index unique scan)
索引范圍掃描(index range scan)
索引全掃描(index full scan)
索引快速掃描(index fast full scan)
(1) 索引唯一掃描(index unique scan)
通過唯一索引查找一個數值經常返回單個ROWID。如果該唯一索引有多個列組成(即組合索引)，則至少要有組合索引的引導列參與到該查詢中，如創建一個索引：create index idx_test on emp(ename, deptno, loc)。則select ename from emp where ename = ‘JACK' and deptno = ‘DEV'語句可以使用該索引。如果該語句只返回一行，則存取方法稱為索引唯一掃描。而select ename from emp where deptno = ‘DEV'語句則不會使用該索引，因為where子句種沒有引導列。如果存在UNIQUE 或PRIMARY KEY 約束（它保證了語句只存取單行）的話，Oracle經常實現唯一性掃描。
使用唯一性約束的例子：
SQL> explain plan for
select empno,ename from emp where empno=10;
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1
(2) 索引范圍掃描(index range scan)
使用一個索引存取多行數據，同上面一樣，如果索引是組合索引，如(1)所示，而且select ename from emp where ename = ‘JACK' and deptno = ‘DEV'語句返回多行數據，雖然該語句還是使用該組合索引進行查詢，可此時的存取方法稱為索引范圍掃描。在唯一索引上使用索引范圍掃描的典型情況下是在謂詞(where限制條件)中使用了范圍操作符(如>、<、<>、>=、<=、between)
使用索引范圍掃描的例子：
SQL> explain plan for select empno,ename from emp
where empno > 7876 order by empno;
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]
在非唯一索引上，謂詞col = 5可能返回多行數據，所以在非唯一索引上都使用索引范圍掃描。
使用index rang scan的3種情況：
(a) 在唯一索引列上使用了range操作符(> < <> >= <= between)
(b) 在組合索引上，只使用部分列進行查詢，導致查詢出多行
(c) 對非唯一索引列上進行的任何查詢。
(3) 索引全掃描(index full scan)
與全表掃描對應，也有相應的全索引掃描。在某些情況下，可能進行全索引掃描而不是范圍掃描，需要注意的是全索引掃描只在CBO模式下才有效。CBO根據統計數值得知進行全索引掃描比進行全表掃描更有效時，才進行全索引掃描，而且此時查詢出的數據都必須從索引中可以直接得到。
全索引掃描的例子：
An Index full scan will not perform single block i/o's and so it may prove to be inefficient.
e.g.
Index BE_IX is a concatenated index on big_emp (empno, ename)
SQL> explain plan for select empno, ename from big_emp order by empno,ename;
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=26
INDEX FULL SCAN BE_IX [ANALYZED]
(4) 索引快速掃描(index fast full scan)
掃描索引中的所有的數據塊，與 index full scan很類似，但是一個顯著的區別就是它不對查詢出的數據進行排序，即數據不是以排序順序被返回。在這種存取方法中，可以使用多塊讀功能，也可以使用并行讀入，以便獲得最大吞吐量與縮短執行時間。
索引快速掃描的例子：
BE_IX索引是一個多列索引：big_emp (empno,ename)
SQL> explain plan for select empno,ename from big_emp;
Query Plan
------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
INDEX FAST FULL SCAN BE_IX [ANALYZED]
只選擇多列索引的第2列：
SQL> explain plan for select ename from big_emp;
Query Plan
------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
INDEX FAST FULL SCAN BE_IX [ANALYZED]
表之間的連接
Join是一種試圖將兩個表結合在一起的謂詞，一次只能連接2個表，表連接也可以被稱為表關聯。在后面的敘述中，我們將會使用”row source”來代替”表”，因為使用row source更嚴謹一些，并且將參與連接的2個row source分別稱為row source1和row source 2。Join過程的各個步驟經常是串行操作，即使相關的row source可以被并行訪問，即可以并行的讀取做join連接的兩個row source的數據，但是在將表中符合限制條件的數據讀入到內存形成row source后，join的其它步驟一般是串行的。有多種方法可以將2個表連接起來，當然每種方法都有自己的優缺點，每種連接類型只有在特定的條件下才會發揮出其最大優勢。
row source(表)之間的連接順序對于查詢的效率有非常大的影響。通過首先存取特定的表，即將該表作為驅動表，這樣可以先應用某些限制條件，從而得到一個較小的row source，使連接的效率較高，這也就是我們常說的要先執行限制條件的原因。一般是在將表讀入內存時，應用where子句中對該表的限制條件。
根據2個row source的連接條件的中操作符的不同，可以將連接分為等值連接(如WHERE A.COL3 = B.COL4)、非等值連接(WHERE A.COL3 > B.COL4)、外連接(WHERE A.COL3 = B.COL4(+))。上面的各個連接的連接原理都基本一樣，所以為了簡單期間，下面以等值連接為例進行介紹。在后面的介紹中，都已：
SELECT A.COL1, B.COL2
FROM A, B
WHERE A.COL3 = B.COL4;
為例進行說明，假設A表為Row Soruce1，則其對應的連接操作關聯列為COL 3；B表為Row Soruce2，則其對應的連接操作關聯列為COL 4；
連接類型：
目前為止，無論連接操作符如何，典型的連接類型共有3種：
排序 - - 合并連接(Sort Merge Join (SMJ) )
嵌套循環(Nested Loops (NL) )
哈希連接(Hash Join)
排序 - - 合并連接(Sort Merge Join, SMJ)
內部連接過程：
1) 首先生成row source1需要的數據，然后對這些數據按照連接操作關聯列(如A.col3)進行排序。
2) 隨后生成row source2需要的數據，然后對這些數據按照與sort source1對應的連接操作關聯列(如B.col4)進行排序。
3) 最后兩邊已排序的行被放在一起執行合并操作，即將2個row source按照連接條件連接起來
下面是連接步驟的圖形表示：
MERGE
/ \
SORT SORT
| |
Row Source 1 Row Source 2
如果row source已經在連接關聯列上被排序，則該連接操作就不需要再進行sort操作，這樣可以大大提高這種連接操作的連接速度，因為排序是個極其費資源的操作，特別是對于較大的表。 預先排序的row source包括已經被索引的列(如a.col3或b.col4上有索引)或row source已經在前面的步驟中被排序了。盡管合并兩個row source的過程是串行的，但是可以并行訪問這兩個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]
排序是一個費時、費資源的操作，特別對于大表。基于這個原因，SMJ經常不是一個特別有效的連接方法，但是如果2個row source都已經預先排序，則這種連接方法的效率也是蠻高的。
嵌套循環(Nested Loops, NL)
這個連接方法有驅動表(外部表)的概念。其實，該連接過程就是一個2層嵌套循環，所以外層循環的次數越少越好，這也就是我們為什么將小表或返回較小row source的表作為驅動表(用于外層循環)的理論依據。但是這個理論只是一般指導原則，因為遵循這個理論并不能總保證使語句產生的I/O次數最少。有時不遵守這個理論依據，反而會獲得更好的效率。如果使用這種方法，決定使用哪個表作為驅動表很重要。有時如果驅動表選擇不正確，將會導致語句的性能很差、很差。
內部連接過程：
Row source1的Row 1 -------------- -- Probe -> Row source 2
Row source1的Row 2 -------------- -- Probe -> Row source 2
Row source1的Row 3 -------------- -- Probe -> Row source 2
…….
Row source1的Row n -------------- -- Probe -> Row source 2
從內部連接過程來看，需要用row source1中的每一行，去匹配row source2中的所有行，所以此時保持row source1盡可能的小與高效的訪問row source2(一般通過索引實現)是影響這個連接效率的關鍵問題。這只是理論指導原則，目的是使整個連接操作產生最少的物理I/O次數，而且如果遵守這個原則，一般也會使總的物理I/O數最少。但是如果不遵從這個指導原則，反而能用更少的物理I/O實現連接操作，那盡管違反指導原則吧！因為最少的物理I/O次數才是我們應該遵從的真正的指導原。
在上面的連接過程中，我們稱Row source1為驅動表或外部表。Row Source2被稱為被探查表或內部表。
在NESTED LOOPS連接中，Oracle讀取row source1中的每一行，然后在row sourc2中檢查是否有匹配的行，所有被匹配的行都被放到結果集中，然后處理row source1中的下一行。這個過程一直繼續，直到row source1中的所有行都被處理。這是從連接操作中可以得到第一個匹配行的最快的方法之一，這種類型的連接可以用在需要快速響應的語句中，以響應速度為主要目標。
如果driving row source(外部表)比較小，并且在inner row source(內部表)上有唯一索引，或有高選擇性非唯一索引時，使用這種方法可以得到較好的效率。NESTED LOOPS有其它連接方法沒有的的一個優點是：可以先返回已經連接的行，而不必等待所有的連接操作處理完才返回數據，這可以實現快速的響應時間。
如果不使用并行操作，最好的驅動表是那些應用了where 限制條件后，可以返回較少行數據的的表，所以大表也可能稱為驅動表，關鍵看限制條件。對于并行查詢，我們經常選擇大表作為驅動表，因為大表可以充分利用并行功能。當然，有時對查詢使用并行操作并不一定會比查詢不使用并行操作效率高，因為最后可能每個表只有很少的行符合限制條件，而且還要看你的硬件配置是否可以支持并行(如是否有多個CPU，多個硬盤控制器)，所以要具體問題具體對待。
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)
這種連接是在oracle 7.3以后引入的，從理論上來說比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連接的例子：
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
要使哈希連接有效，需要設置HASH_JOIN_ENABLED=TRUE，缺省情況下該參數為TRUE，另外，不要忘了還要設置hash_area_size參數，以使哈希連接高效運行，因為哈希連接會在該參數指定大小的內存中運行，過小的參數會使哈希連接的性能比其他連接方式還要低。
總結一下，在哪種情況下用哪種連接方法比較好：
排序 - - 合并連接(Sort Merge Join, SMJ)：
a) 對于非等值連接，這種連接方式的效率是比較高的。
b) 如果在關聯的列上都有索引，效果更好。
c) 對于將2個較大的row source做連接，該連接方法比NL連接要好一些。
d) 但是如果sort merge返回的row source過大，則又會導致使用過多的rowid在表中查詢數據時，數據庫性能下降，因為過多的I/O。
嵌套循環(Nested Loops, NL)：
a) 如果driving row source(外部表)比較小，并且在inner row source(內部表)上有唯一索引，或有高選擇性非唯一索引時，使用這種方法可以得到較好的效率。
b) NESTED LOOPS有其它連接方法沒有的的一個優點是：可以先返回已經連接的行，而不必等待所有的連接操作處理完才返回數據，這可以實現快速的響應時間。
哈希連接(Hash Join, HJ)：
a) 這種方法是在oracle7后來引入的，使用了比較先進的連接理論，一般來說，其效率應該好于其它2種連接，但是這種連接只能用在CBO優化器中，而且需要設置合適的hash_area_size參數，才能取得較好的性能。
b) 在2個較大的row source之間連接時會取得相對較好的效率，在一個row source較小時則能取得更好的效率。
c) 只能用于等值連接中
笛卡兒乘積(Cartesian Product)
當兩個row source做連接，但是它們之間沒有關聯條件時，就會在兩個row source中做笛卡兒乘積，這通常由編寫代碼疏漏造成(即程序員忘了寫關聯條件)。笛卡爾乘積是一個表的每一行依次與另一個表中的所有行匹配。在特殊情況下我們可以使用笛卡兒乘積，如在星形連接中，除此之外，我們要盡量使用笛卡兒乘積，否則，自己想結果是什么吧！
注意在下面的語句中，在2個表之間沒有連接。
SQL> explain plan for
select emp.deptno,dept,deptno
from emp,dept
Query Plan
------------------------------
SLECT STATEMENT [CHOOSE] Cost=5
MERGE JOIN CARTESIAN
TABLE ACCESS FULL DEPT
SORT JOIN
TABLE ACCESS FULL EMP
CARTESIAN關鍵字指出了在2個表之間做笛卡爾乘積。假如表emp有n行，dept表有m行，笛卡爾乘積的結果就是得到n * m行結果。 |