Oracle sql執行計划解析
https://blog.csdn.net/xybelieve1990/article/details/50562963
Oracle優化器
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代價。
¨I/O代價是將數據從磁盤讀入內存所需的代價。訪問數據包括將數據文件中數據塊的內容讀入到SGA的數據高速緩存中，在一般情況下，該代價是處理一個查詢所需要的最主要代價，所以我們在優化時，一個基本原則就是降低查詢所產生的I/O總次數。
¨CPU代價是處理在內存中數據所需要的代價，如一旦數據被讀入內存，則我們在識別出我們需要的數據后，在這些數據上執行排序(sort)或連接(join)操作，這需要耗費CPU資源。對於需要訪問跨節點(即通常說的服務器)數據庫上數據的查詢來說，存在network代價，用來量化傳輸操作耗費的資源。查詢遠程表的查詢或執行分布式連接的查詢會在network代價方面花費比較大。
判斷當前數據庫使用何種優化器
由optimizer_mode初始化參數決定的。該參數可能的取值為：first_rows_[1 | 10 | 100 | 1000] | first_rows | all_rows | choose | rule。具體解釋如下：
¨RULE為使用RBO優化器。
¨CHOOSE則是根據實際情況，如果數據字典中包含被引用的表的統計數據，即引用的對象已經被分析，則就使用CBO優化器，否則為RBO優化器。
¨ALL_ROWS為CBO優化器使用的第一種具體的優化方法，是以數據的吞吐量為主要目標，以便可以使用最少的資源完成語句。
¨FIRST_ROWS為優化器使用的第二種具體的優化方法，是以數據的響應時間為主要目標，以便快速查詢出開始的幾行數據。
¨FIRST_ROWS_[1 | 10 | 100 | 1000] 為優化器使用的第三種具體的優化方法，讓優化器選擇一個能夠把響應時間減到最小的查詢執行計划，以迅速產生查詢結果的前 n 行。該參數為ORACLE 9I新引入的。
¨查看命令：show parameter OPTIMIZER_MODE
優化定義
什么是優化：
優化是選擇最有效的執行計划來執行SQL語句的過程，這是在處理任何數據的語句（SELECT,INSERT,UPDATE或DELETE）中的一個重要步驟。對Oracle來說，執行這樣的語句有許多不同的方法，譬如說，將隨着以什么順序訪問哪些表或索引的不同而不同。所使用的執行計划可以決定語句能執行得有多快。Oracle中稱之為優化器（Optimizer）的組件用來選擇這種它認為最有效的執行計划。
相關概念解釋
共享SQL語句
為了不重復解析相同的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訪問數據的存取方法
訪問路徑(方法) -- access path
優化器在形成執行計划時需要做的一個重要選擇是如何從數據庫查詢出需要的數據。對於SQL語句存取的任何表中的任何行，可能存在許多存取路徑(存取方法)，通過它們可以定位和查詢出需要的數據。優化器選擇其中自認為是最優化的路徑。在物理層，oracle讀取數據，一次讀取的最小單位為數據庫塊(由多個連續的操作系統塊組成)，一次讀取的最大值由操作系統一次I/O的最大值與multiblock參數共同決定，所以即使只需要一行數據，也是將該行所在的數據庫塊讀入內存。邏輯上，oracle用如下存取方法訪問數據：
¨1 全表掃描（Full Table Scans, FTS）
¨2 通過ROWID的表存取（Table Access by ROWID或rowid lookup）
¨3 索引掃描（Index Scan或index lookup）
全表掃描
為實現全表掃描，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%，或你想使用並行查詢功能時。
n使用全表掃描的例子：
¨SQL> explain plan for select * from dual;
¨Query Plan
¨-----------------------------------------
¨SELECT STATEMENT [CHOOSE] Cost=
¨TABLE ACCESS FULL DUAL
通過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]
索引掃描（Index Scan或index lookup）
通過index查找到數據對應的rowid值(對於非唯一索引可能返回多個rowid值)，然后根據rowid直接從表中得到具體的數據。一個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為使用的進行索引查找的索引名字。 根據索引的類型與where限制條件的不同，有4種類型的索引掃描：
１、索引唯一掃描(index unique scan)
２、索引范圍掃描(index range scan)
３、索引全掃描(index full scan)
４、索引快速掃描(index fast full scan)
索引唯一掃描(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
索引范圍掃描(index range scan)
使用索引存取多行數據，如果索引是組合索引，如索引唯一掃描所示，且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種情況：
¨在唯一索引列上使用了range操作符(> < <> >= <= between)
¨在組合索引上，只使用部分列進行查詢，導致查詢出多行
索引全掃描(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]
索引快速掃描(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=1INDEX FAST FULL SCAN BE_IX [ANALYZED]
表連接
Join是一種試圖將兩個表結合在一起的謂詞，一次只能連接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；
連接類型：
-
排序 - - 合並連接 (Sort Merge Join (SMJ) )
-
嵌套循環 (Nested Loops (NL) )
-
哈希連接 (Hash Join)
4.笛卡兒乘積(Cartesian Product)
排序 - - 合並連接(Sort Merge Join (SMJ) )
內部連接過程：
-
首先生成row source1需要的數據，然后對這些數據按照連接操作關聯列(如A.col3)進行排序。
-
隨后生成row source2需要的數據，然后對這些數據按照與sortsource1對應的連接操作關聯列(如B.col4)進行排序。
-
最后兩邊已排序的行被放在一起執行合並操作，即將2個rowsource按照連接條件連接起來。
如果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) )
該連接過程是一個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)
理論上來說比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個表之間沒有連接。
¨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 EMPCARTESIAN關鍵字指出了在2個表之間做笛卡爾乘積。假如表emp有n行，dept表有m行，笛卡爾乘積的結果就是得到n * m行結果。
在哪種情況下用哪種連接方法比較好：
1.排序 - - 合並連接(Sort Merge Join, SMJ)：
ü 對於非等值連接，這種連接方式的效率是比較高的。
ü 如果在關聯的列上都有索引，效果更好。
ü 對將2個較大的row source做連接，該連接方法比NL連接要好些。
ü 但是如果sort merge返回的row source過大，則又會導致使用過多的rowid在表中查詢數據時，數據庫性能下降，因為過多的I/O。
2.嵌套循環(Nested Loops, NL)：
ü 如果driving row source(外部表)比較小，並且在inner row source(內部表)上有唯一索引，或有高選擇性非唯一索引時，使用這種方法可以得到較好的效率。
NESTED LOOPS有其它連接方法沒有的的一個優點是：可以先返回已經 連接的行，而不必等待所有的連接操作處理完才返回數據，這可以實現快速的響應時間。
3.哈希連接(Hash Join, HJ)：
ü 此方法是在oracle7后來引入的，使用了比較先進的連接理論，其效率應該好於其它2種連接，但是這種連接只能用在CBO優化器中，而且需要設置合適的hash_area_size參數，才能 取得較好的性能。
ü 在2個較大的row source之間連接時會取得相對較好的效率，在一個 row source較小時則能取得更好的效率。
ü 只能用於等值連接中。
如何產生執行計划
要為一個語句產生執行計划，有三種方法，我們這里只介紹最簡單的方法：在plsql中新建Explain Plan Window，然后將要產生執行計划的sql放到該窗口中執行，或者在普通的SQL Window中選擇sql語句，按F5也可以產生執行計划窗口。
需要注意的是，以上方法並不會真正執行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部分。
¨ SELECT STATEMENT Optimizer=CHOOSE Cost=
¨ SELECT STATEMENT Optimizer=CHOOSE
¨ 這樣我們從Optimizer后面的信息中可以得出執行該語句時到底用了什么樣的優化器。特別的，如果Optimizer=ALL_ROWS|FIRST_ROWS| FIRST_ROWS_n，則使用的是CBO優化器；
如果Optimizer=RULE，則使用的是RBO優化器。cost屬性的值是一個在oracle內部用來比較各個執行計划所耗費代價的值，從而使優化器可以選擇最好的執行計划。不同語句的cost值不具有可比性，只能對同一個語句的不同執行計划的cost值進行比較。[:Q65001] 表明該部分查詢是以並行方式運行的。里面的數據表示這個操作是由並行查詢的一個slave進程處理的，以便該操作可以區別於串行執行的操作。[ANALYZED] 表明操作中引用的對象被分析過了，在數據字典中有該對象的統計信息可以供CBO使用。
例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 SQLNet to client
430 bytes received via SQLNet 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采用正確的連接順序。如下所示：
¨ select /*+ ordered */ A.col4
¨ from B,A,C
¨ where B.col3 = 10
¨ and A.col1 = B.col1
¨ and A.col2 = C.col2
¨ and C.col3 = 5
n通過執行計划如何判斷驅動表：
在執行計划中，需要知道哪個操作是先執行的，哪個操作是后執行的，這對於判斷哪個表為驅動表有用處。判斷之前，如果對表的訪問是通過rowid，且該rowid的值是從索引掃描中來得，則將該索引掃描先從執行計划中暫時去掉。然后在執行計划剩下的部分中，判斷執行順序的指導原則就是：最右、最上的操作先執行。具體解釋如下：
得到去除妨礙判斷的索引掃描后的執行計划：
¨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'
¨7 1 SORT (JOIN)
¨8 7 TABLE ACCESS (FULL) OF 'C'
通過執行計划如何判斷驅動表：
談論上下關系時，只對連續的、縮進一致的行有效。
從這個圖中我們可以看到，對於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語句進行更改，使優化器可以選擇正確的驅動表。
干預執行計划
使用hints提示：
基於代價的優化器在絕大多數情況下它會選擇正確的優化器，減輕了DBA的負擔。但有時它也聰明反被聰明誤，選擇了很差的執行計划，使某個語句的執行變得奇慢無比。此時就需要DBA進行人為的干預，告訴優化器使用我們指定的存取路徑或連接類型生成執行計划，從而使語句高效的運行。例如: 對於一個特定的語句，執行全表掃描要比執行索引掃描更有效，則我們可以指示優化器使用全表掃描。在ORACLE中，是通過為語句添加hints(提示)來實現干預優化器優化的目的。
hints是oracle提供的一種機制，用來告訴優化器按照我們的告訴它的方式生成執行計划。可以用hints來實現：
¨1) 使用的優化器的類型
¨2) 基於代價優化器的優化目標，是all_rows還是first_rows。
¨3) 表的訪問路徑，是全表掃描、索引掃描，還是直接利用rowid。
¨4) 表之間的連接類型
¨5) 表之間的連接順序
¨6) 語句的並行程度
關於hints的介紹到此為止，大家有興趣自己去了解。