本文源自TTT BLOG，原文地址：http://blog.chinaunix.net/u3/107265/showart_2192657.html

簡介：

本文全面詳細介紹執行計劃的相關的概念，訪問資料的存取方法，表之間的連線等內容。

並有總結和概述，便於理解與記憶!

+++

---

一．相關的概念

Rowid的概念

Recursive 概念

Predicate(謂詞)

DRiving Table(驅動表)

Probed Table(被探查表)

組合索引(concatenated )

可選擇性(selectivity)

二．oracle訪問資料的存取方法

1）全表掃描（Full Table Scans， FTS）

2）透過ROWID的表存取（Table Access by ROWID或rowid lookup）

3）索引掃描（Index Scan或index lookup）有4種型別的索引掃描：

　（1）索引唯一掃描（index unique scan）

　（2）索引範圍掃描（index range scan）

在非唯一索引上都使用索引範圍掃描。使用index rang scan的3種情況：

　　（a）在唯一索引列上使用了range運算子（> < <> >= <= between）

　　（b）在組合索引上，只使用部分列進行查詢，導致查詢出多行

　　（c）對非唯一索引列上進行的任何查詢。　　

　（3）索引全掃描（index full scan）

　（4）索引快速掃描（index fast full scan）

三、表之間的連線

1，排序 - - 合併連線（Sort Merge Join， SMJ）

2，巢狀迴圈（Nested Loops， NL）

3，雜湊連線（Hash Join， HJ）

另外，笛卡兒乘積（Cartesian Product）

總結Oracle連線方法

Oracle執行計劃總結概述

+++

　　一．相關的概念

　　Rowid的概念：rowid是一個偽列，既然是偽列，那麼這個列就不是使用者定義，而是系統自己給加上的。對每個表都有一個rowid的偽列，但是表中並不物理儲存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訪問資料的存取方法

　　1）全表掃描（Full Table Scans， FTS）
　　為實現全表掃描，Oracle讀取表中所有的行，並檢查每一行是否滿足語句的WHERE限制條件一個多塊讀操作可以使一次I/O能讀取多塊資料塊（db_block_multiblock_read_count引數設定），而不是隻讀取一個資料塊，這極大的減少了I/O總次數，提高了系統的吞吐量，所以利用多塊讀的方法可以十分高效地實現全表掃描，而且只有在全表掃描的情況下才能使用多塊讀操作。在這種訪問模式下，每個資料塊只被讀一次。
　　使用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存取單行資料的最快方法。
　　這種存取方法不會用到多塊讀操作，一次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

　　但是如果查詢的資料能全在索引中找到，就可以避免進行第2步操作，避免了不必要的I/O，此時即使透過索引掃描取出的資料比較多，效率還是很高的
　　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.如果存在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）
　　使用一個索引存取多行資料，在唯一索引上使用索引範圍掃描的典型情況下是在謂詞（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）
　　與全表掃描對應，也有相應的全索引掃描。而且此時查詢出的資料都必須從索引中可以直接得到。
　　全索引掃描的例子：
　　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（+））。上面的各個連線的連線原理都基本一樣，所以為了簡單期間，下面以等值連線為例進行介紹。
　　在後面的介紹中，都以以下Sql為例進行說明：
　　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）

　　另外，還有一種Cartesian product（笛卡爾積），一般情況下，儘量避免使用。

　　1，排序 - - 合併連線（Sort Merge Join， SMJ）

　　內部連線過程：
　　1）首先生成row source1需要的資料，然後對這些資料按照連線操作關聯列（如A.col3）進行排序。
　　2）隨後生成row source2需要的資料，然後對這些資料按照與sort source1對應的連線操作關聯列（如B.col4）進行排序。
　　3）最後兩邊已排序的行被放在一起執行合併操作，即將2個row source按照連線條件連線起來

　　下面是連線步驟的圖形表示：
　　MERGE
　　/\
　　SORTSORT
　　||
　　Row Source 1Row 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都已經預先排序，則這種連線方法的效率也是蠻高的。

　　2，巢狀迴圈（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]

　　3，雜湊連線（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引數，以使雜湊連線高效執行，因為雜湊連線會在該引數指定大小的記憶體中執行，過小的引數會使雜湊連線的效能比其他連線方式還要低。

　　另外，笛卡兒乘積（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行結果。

　　最後，總結一下，在哪種情況下用哪種連線方法比較好：

　　排序 - - 合併連線（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）只能用於等值連線中

　　+++
　　Oracle執行計劃的概述
　　---

　　Oracle執行計劃的相關概念：

　　Rowid：系統給oracle資料的每行附加的一個偽列，包含資料表名稱，資料庫id，儲存資料庫id以及一個流水號等資訊，rowid在行的生命週期內唯一。
　　Recursive sql：為了執行使用者語句，系統附加執行的額外操作語句，譬如對資料字典的維護等。
　　Row source（行源）：oracle執行步驟過程中，由上一個操作返回的符合條件的行的集合。
　　Predicate（謂詞）：where後的限制條件。
　　Driving table（驅動表）：又稱為連線的外層表，主要用於巢狀與hash連線中。一般來說是將應用限制條件後，返回較少行源的表作為驅動表。在後面的描述中，將driving table稱為連線操作的row source 1。
　　Probed table（被探查表）：連線的內層表，在我們從driving table得到具體的一行資料後，在probed table中尋找符合條件的行，所以該表應該為較大的row source，並且對應連線條件的列上應該有索引。在後面的描述中，一般將該表稱為連線操作的row source 2.
　　Concatenated index（組合索引）：一個索引如果由多列構成，那麼就稱為組合索引，組合索引的第一列為引導列，只有謂詞中包含引導列時，索引才可用。
　　可選擇性：表中某列的不同數值數量/表的總行數如果接近於1，則列的可選擇性為高。

　　Oracle訪問資料的存取方法：

　　Full table scans, FTS(全表掃描)：透過設定db_block_multiblock_read_count可以設定一次IO能讀取的資料塊個數，從而有效減少全表掃描時的IO總次數，也就是透過預讀機制將將要訪問的資料塊預先讀入記憶體中。只有在全表掃描情況下才能使用多塊讀操作。
　　Table Access by rowed（透過rowid存取表，rowid lookup）：由於rowid中記錄了行儲存的位置，所以這是oracle存取單行資料的最快方法。
　　Index scan（索引掃描index lookup）：在索引中，除了儲存每個索引的值外，索引還儲存具有此值的行對應的rowid值，索引掃描分兩步1，掃描索引得到rowid；2，透過 rowid讀取具體資料。每步都是單獨的一次IO，所以如果資料經限制條件過濾後的總量大於原表總行數的5%－10％,則使用索引掃描效率下降很多。而如果結果資料能夠全部在索引中找到，則可以避免第二步操作，從而加快檢索速度。
　　根據索引型別與where限制條件的不同，有4種型別的索引掃描：
　　Index unique scan（索引唯一掃描）：存在unique或者primary key的情況下，返回單個rowid資料內容。
　　Index range scan（索引範圍掃描）：1，在唯一索引上使用了range運算子（>,<,<>,>=,<=,between）；2，在組合索引上，只使用部分列進行查詢；3，對非唯一索引上的列進行的查詢。
　　Index full scan（索引全掃描）：需要查詢的資料從索引中可以全部得到。
　　Index fast full scan（索引快速掃描）：與index full scan類似，但是這種方式下不對結果進行排序。

　　目前為止，典型的連線型別有3種：

　　Sort merge join（SMJ排序－合併連線）：首先生產driving table需要的資料，然後對這些資料按照連線操作關聯列進行排序；然後生產probed table需要的資料，然後對這些資料按照與driving table對應的連線操作列進行排序；最後兩邊已經排序的行被放在一起執行合併操作。排序是一個費時、費資源的操作，特別對於大表。所以smj通常不是一個特別有效的連線方法，但是如果driving table和probed table都已經預先排序，則這種連線方法的效率也比較高。
　　Nested loops（NL巢狀迴圈）：連線過程就是將driving table和probed table進行一次巢狀迴圈的過程。就是用driving table的每一行去匹配probed table 的所有行。Nested loops可以先返回已經連線的行，而不必等待所有的連線操作處理完成才返回資料，這可以實現快速的響應時間。
　　Hash join（雜湊連線）：較小的row source被用來構建hash table與bitmap，第二個row source用來被hashed，並與第一個row source生產的hash table進行匹配。以便進行進一步的連線。當被構建的hash table與bitmap能被容納在記憶體中時，這種連線方式的效率極高。但需要設定合適的hash_area_size引數且只能用於等值連線中。
　　另外，還有一種連線型別：Cartesian product（笛卡爾積）：表的每一行依次與另外一表的所有行匹配，一般情況下，儘量避免使用。

Oracle執行計劃詳解

相關文章