ORACLE執(zhí)行計(jì)劃.doc

1，什么是執(zhí)行計(jì)劃所謂執(zhí)行計(jì)劃，顧名思義，就是對(duì)一個(gè)查詢?nèi)蝿?wù)，做出一份怎樣去完成任務(wù)的詳細(xì)方案。舉個(gè)生活中的例子，我從珠海要去英國(guó)，我可以選擇先去香港然后轉(zhuǎn)機(jī)，也可以先去北京轉(zhuǎn)機(jī)，或者去廣州也可以。但是到底怎樣去英國(guó)劃算，也就是我的費(fèi)用最少，這是一件值得考究的事情。同樣對(duì)于查詢而言，我們提交的SQL僅僅是描述出了我們的目的地是英國(guó)，但至于怎么去，通常我們的SQL中是沒(méi)有給出提示信息的，是由數(shù)據(jù)庫(kù)來(lái)決定的。我們先簡(jiǎn)單的看一個(gè)執(zhí)行計(jì)劃的對(duì)比：SQL set autotrace traceonly執(zhí)行計(jì)劃一：SQL select count(*) from t; COUNT(*) - 24815 Execution Plan 0SELECT STATEMENT Optimizer=CHOOSE 10 SORT (AGGREGATE) 21 TABLE Access (FULL) OF T執(zhí)行計(jì)劃二：SQL select count(*) from t; COUNT(*) 24815 Execution Plan 0SELECT STATEMENT Optimizer=CHOOSE (Cost=26 Card=1) 10 SORT (AGGREGATE) 21 INDEX (FULL SCAN) OF T_INDEX (NON-UNIQUE) (Cost=26 Card=28180)這兩個(gè)執(zhí)行計(jì)劃中，第一個(gè)表示求和是通過(guò)進(jìn)行全表掃描來(lái)做的，把整個(gè)表中數(shù)據(jù)讀入內(nèi)存來(lái)逐條累加;第二個(gè)表示根據(jù)表中索引，把整個(gè)索引讀進(jìn)內(nèi)存來(lái)逐條累加，而不用去讀表中的數(shù)據(jù)。但是這兩種方式到底哪種快呢?通常來(lái)說(shuō)可能二比一快，但也不是絕對(duì)的。這是一個(gè)很簡(jiǎn)單的例子演示執(zhí)行計(jì)劃的差異。對(duì)于復(fù)雜的SQL(表連接、嵌套子查詢等)，執(zhí)行計(jì)劃可能幾十種甚至上百種，但是到底那種最好呢?我們事前并不知道，數(shù)據(jù)庫(kù)本身也不知道，但是數(shù)據(jù)庫(kù)會(huì)根據(jù)一定的規(guī)則或者統(tǒng)計(jì)信息(statistics)去選擇一個(gè)執(zhí)行計(jì)劃，通常來(lái)說(shuō)選擇的是比較優(yōu)的，但也有選擇失誤的時(shí)候，這就是這次討論的價(jià)值所在。Oracle優(yōu)化器模式Oracle優(yōu)化器有兩大類(lèi)，基于規(guī)則的和基于代價(jià)的，在SQLPLUS中我們可以查看init文件中定義的缺省的優(yōu)化器模式。SQL show parameters optimizer_mode NAME TYPEVALUE optimizer_mode string CHOOSE SQL這是Oracle8.1.7 企業(yè)版，我們可以看出，默認(rèn)安裝后數(shù)據(jù)庫(kù)優(yōu)化器模式為CHOOSE,我們還可以設(shè)置為 RULE、FIRST_ROWS,ALL_ROWS?？梢栽趇nit文件中對(duì)整個(gè)instance的所有會(huì)話設(shè)置，也可以單獨(dú)對(duì)某個(gè)會(huì)話設(shè)置：SQL ALTER SESSION SET optimizer_mode= RULE; 會(huì)話已更改。 SQLALTER SESSION SET optimizer_mode= FIRST_ROWS; 會(huì)話已更改。 SQLALTER SESSION SET optimizer_mode= ALL_ROWS; 會(huì)話已更改。基于規(guī)則的查詢，數(shù)據(jù)庫(kù)根據(jù)表和索引等定義信息，按照一定的規(guī)則來(lái)產(chǎn)生執(zhí)行計(jì)劃;基于代價(jià)的查詢，數(shù)據(jù)庫(kù)根據(jù)搜集的表和索引的數(shù)據(jù)的統(tǒng)計(jì)信息(通過(guò)analyze 命令或者使用dbms_stats包來(lái)搜集)綜合來(lái)決定選取一個(gè)數(shù)據(jù)庫(kù)認(rèn)為最優(yōu)的執(zhí)行計(jì)劃(實(shí)際上不一定最優(yōu))。RULE是基于規(guī)則的，CHOOSE表示如果查詢的表存在搜集的統(tǒng)計(jì)信息則基于代價(jià)來(lái)執(zhí)行(在CHOOSE模式下Oracle采用的是 FIRST_ROWS)，否則基于規(guī)則來(lái)執(zhí)行。在基于代價(jià)的兩種方式中，F(xiàn)IRST_ROWS指執(zhí)行計(jì)劃采用最少資源盡快的返回部分結(jié)果給客戶端，對(duì)于排序分頁(yè)頁(yè)顯示這種查詢尤其適用，ALL_ROWS指以總體消耗資源最少的方式返回結(jié)果給客戶端。基于規(guī)則的模式下，數(shù)據(jù)庫(kù)的執(zhí)行計(jì)劃通常比較穩(wěn)定。但在基于代價(jià)的模式下，我們才有更大的機(jī)會(huì)選擇最優(yōu)的執(zhí)行計(jì)劃。也由于Oracle的很多查詢方面的特性必須在基于代價(jià)的模式下才能體現(xiàn)出來(lái)，所以我們通常不選擇RULE(并且Oracle宣稱從 Oracle 10i版本數(shù)據(jù)庫(kù)開(kāi)始將不再支持 RULE)。既然是基于代價(jià)的模式，也就是說(shuō)執(zhí)行計(jì)劃的選擇是根據(jù)表、索引等定義和數(shù)據(jù)的統(tǒng)計(jì)信息來(lái)決定的，這個(gè)統(tǒng)計(jì)信息是根據(jù) analyze 命令或者dbms_stats包來(lái)定期搜集的。首先存在著一種可能，就是由于搜集信息是一個(gè)很消耗資源和時(shí)間的動(dòng)作，尤其當(dāng)表數(shù)據(jù)量很大的時(shí)候，因?yàn)樗鸭畔⑹菍?duì)整個(gè)表數(shù)據(jù)進(jìn)行重新的完全統(tǒng)計(jì)，所以這是我們必須慎重考慮的問(wèn)題。我們只能在服務(wù)器空閑的時(shí)候定期的進(jìn)行信息搜集。這說(shuō)明我們?cè)谝欢螘r(shí)期內(nèi)，統(tǒng)計(jì)信息可能和數(shù)據(jù)庫(kù)本身的數(shù)據(jù)并不吻合;另外就是Oracle的統(tǒng)計(jì)數(shù)據(jù)本身也存在著不精確部分(詳細(xì)參考Oracle DOCUMENT)，更重要的一個(gè)問(wèn)題就是及時(shí)統(tǒng)計(jì)數(shù)據(jù)相對(duì)已經(jīng)比較準(zhǔn)確，但是Oracle的優(yōu)化器的選擇也并不是始終是最優(yōu)的方案。這也倚賴于Oracle對(duì)不同執(zhí)行計(jì)劃的代價(jià)的計(jì)算規(guī)則(我們通常是無(wú)法知道具體的計(jì)算規(guī)則的)。這好比我們決定從香港還是從北京去英國(guó)，車(chē)票、機(jī)票等實(shí)際價(jià)格到底是怎么核算出來(lái)的我們并不知道，或者說(shuō)我們現(xiàn)在了解的價(jià)格信息，在我們乘車(chē)前往的時(shí)候，真實(shí)價(jià)格跟我們的預(yù)算已經(jīng)發(fā)生了變化。所有的因素，都將影響我們的整個(gè)開(kāi)銷(xiāo)。執(zhí)行計(jì)劃穩(wěn)定性能帶給我們什么Oracle存在著執(zhí)行計(jì)劃選擇失誤的可能。這也是我們經(jīng)常遇見(jiàn)的一些現(xiàn)象，比如總有人說(shuō)我的程序在測(cè)試數(shù)據(jù)庫(kù)中跑的很好，但在產(chǎn)品數(shù)據(jù)庫(kù)上就是跑的很差，甚至后者硬件條件比前者還好，這到底是為什么?硬件資源、統(tǒng)計(jì)信息、參數(shù)設(shè)置都可能對(duì)執(zhí)行計(jì)劃產(chǎn)生影響。由于因素太多，我們總是對(duì)未來(lái)懷著一種莫名的恐懼，我的產(chǎn)品數(shù)據(jù)庫(kù)上線后到底跑的好不好?于是Oracle提供了一種穩(wěn)定執(zhí)行計(jì)劃的能力，也就是把在測(cè)試環(huán)境中的運(yùn)行良好的執(zhí)行計(jì)劃所產(chǎn)生的OUTLINES移植到產(chǎn)品數(shù)據(jù)庫(kù)，使得執(zhí)行計(jì)劃不會(huì)隨著其他因素的變化而變化。那么OUTLINES是什么呢?先要介紹一個(gè)內(nèi)容，Oracle提供了在SQL中使用HINTS來(lái)引導(dǎo)優(yōu)化器產(chǎn)生我們想要的執(zhí)行計(jì)劃的能力。這在多表連接、復(fù)雜查詢中特別有效。HINTS的類(lèi)型很多，可以設(shè)置優(yōu)化器目標(biāo)(RULE、CHOOSE、FIRST_ROWS、ALL_ROWS)，可以指定表連接的順序，可以指定使用哪個(gè)表的哪個(gè)索引等等，可以對(duì)SQL進(jìn)行很多精細(xì)的控制。通過(guò)這種方式產(chǎn)生我們想要的執(zhí)行計(jì)劃的這些HINTS,Oracle可以存儲(chǔ)這些HINTS，我們稱之為OUTLINES。通過(guò)STORE OUTLINES可以使得我們擁有以后產(chǎn)生相同執(zhí)行計(jì)劃的能力，也就是使我們擁有了穩(wěn)定執(zhí)行計(jì)劃的能力。這里想給出一個(gè)附加的說(shuō)明就是，實(shí)際上，我們通過(guò)工具改寫(xiě)SQL，比如使用SQLEXPERT改寫(xiě)后的SQL，這些不僅僅是加了HINTS而且文本都已經(jīng)發(fā)生了變化的SQL，也可以存儲(chǔ)OUTLINES，并可被應(yīng)用到應(yīng)用中。但這不是一定生效，我們必須測(cè)試檢查是否生效。但由于就算給了錯(cuò)誤的OUTLINES,數(shù)據(jù)庫(kù)在執(zhí)行的時(shí)候，也只是忽略過(guò)去重新生成執(zhí)行計(jì)劃而不會(huì)返回錯(cuò)誤，所以我們才敢放心的這么使用。當(dāng)然在Oracle文檔中并沒(méi)有指明可以這樣做，文檔中只是說(shuō)明，如果存在OUTLINES的同時(shí)又在SQL中加了HINTS，則會(huì)使用OUTLINES而忽略HINTS。這個(gè)功能在LECCO將發(fā)布的產(chǎn)品中會(huì)使用這一功能，這樣可以將SQL EXPERT的改寫(xiě)SQL的能力和穩(wěn)定執(zhí)行計(jì)劃的能力結(jié)合起來(lái)，那么我們就對(duì)不能更改源代碼的應(yīng)用具有了相當(dāng)強(qiáng)大的SQL優(yōu)化能力。也許我們會(huì)有疑問(wèn)，假如穩(wěn)定了執(zhí)行計(jì)劃，那還搜集統(tǒng)計(jì)信息干嗎?這是因?yàn)閹讉€(gè)原因造成的，首先，現(xiàn)在的執(zhí)行計(jì)劃對(duì)于未來(lái)發(fā)生了變化的數(shù)據(jù)未必就是合適的，存在著當(dāng)前的執(zhí)行計(jì)劃不滿足未來(lái)數(shù)據(jù)的變化后的效率，而新的統(tǒng)計(jì)信息的情況下所產(chǎn)生的執(zhí)行計(jì)劃也并不是全部都合理的。那這個(gè)時(shí)候，我們可以采用新搜集的統(tǒng)計(jì)信息，但是卻對(duì)新統(tǒng)計(jì)信息下不良的執(zhí)行計(jì)劃采用Oracle提供的執(zhí)行計(jì)劃穩(wěn)定性這個(gè)能力固定執(zhí)行計(jì)劃，這樣結(jié)合起來(lái)我們可以建立滿意的高效的數(shù)據(jù)庫(kù)運(yùn)行環(huán)境。我們還需要關(guān)注的一個(gè)東西，Oracle提供的dbms_stats包除了具有搜集統(tǒng)計(jì)信息的能力，還具有把數(shù)據(jù)庫(kù)中統(tǒng)計(jì)信息(statistics)export/import的能力，還具有只搜集統(tǒng)計(jì)信息而使得統(tǒng)計(jì)信息不應(yīng)用于數(shù)據(jù)庫(kù)的能力(把統(tǒng)計(jì)信息搜集到一個(gè)特定的表中而不是立即生效)，在這個(gè)基礎(chǔ)上我們就可以把統(tǒng)計(jì)信息export出來(lái)再import到一個(gè)測(cè)試環(huán)境中，再運(yùn)行我們的應(yīng)用，在測(cè)試環(huán)境中我們觀察最新的統(tǒng)計(jì)信息會(huì)導(dǎo)致哪些執(zhí)行計(jì)劃發(fā)生變化(DB EXPERT的Plan Version Tracer是模擬不同環(huán)境并自動(dòng)檢查不同環(huán)境中執(zhí)行計(jì)劃變化的工具)，是變好了還是變差了。我們可以把變差的這一部分在測(cè)試環(huán)境中使用hints或者利用工具(SQL EXPERT是在重寫(xiě)SQL這一領(lǐng)域目前最強(qiáng)有力的工具)產(chǎn)生良好的執(zhí)行計(jì)劃的SQL，利用這些SQL可以產(chǎn)生OUTLINES,然后在產(chǎn)品數(shù)據(jù)庫(kù)應(yīng)用最新的統(tǒng)計(jì)信息的同時(shí)移植進(jìn)這些OUTLINES。最后說(shuō)一下我們不得不使用執(zhí)行計(jì)劃穩(wěn)定性能力的場(chǎng)合。我們假定Oracle的優(yōu)化器的選擇都是準(zhǔn)確的，但是優(yōu)化器選擇的基礎(chǔ)就是我們的SQL,這些SQL才從根本上決定了運(yùn)行效率，這是更重要的一個(gè)優(yōu)化的環(huán)節(jié)。SQL是基礎(chǔ)(當(dāng)然數(shù)據(jù)庫(kù)的設(shè)計(jì)是基礎(chǔ)的基礎(chǔ))，一個(gè)SQL寫(xiě)的好不好，就相當(dāng)于我們同樣是要想去英國(guó)，但是我的起點(diǎn)在珠海，你的起點(diǎn)卻在西藏的最邊緣偏僻的一個(gè)地方，那不管你做怎樣的最優(yōu)路線選擇，你都不如我在珠海去英國(guó)所花費(fèi)的代價(jià)小。2，怎么生成的1.Explain planexplain plan for select * from aa;查看結(jié)果：select * from table(dbms_xplan.display(); 2.Autotrace Set timing on -記錄所用時(shí)間Set autot trace -自動(dòng)記錄執(zhí)行計(jì)劃3.SQL_TRACEORACLE SQL_TRACE“SQL TRACE”是Oracle提供的用于進(jìn)行SQL跟蹤的手段，是強(qiáng)有力的輔助診斷工具。在日常的數(shù)據(jù)庫(kù)問(wèn)題診斷和解決中，“SQL TRACE”是非常常用的方法。一般，一次跟蹤可以分為以下幾步：1、界定需要跟蹤的目標(biāo)范圍，并使用適當(dāng)?shù)拿顔⒂盟韪櫋?、經(jīng)過(guò)一段時(shí)間后，停止跟蹤。此時(shí)應(yīng)該產(chǎn)生了一個(gè)跟蹤結(jié)果文件。3、找到跟蹤文件，并對(duì)其進(jìn)行格式化，然后閱讀或分析。本文就“SQL TRACE”的這些使用作簡(jiǎn)單探討，并通過(guò)具體案例對(duì)SQL_TRACE的使用進(jìn)行說(shuō)明。3，怎么查看執(zhí)行計(jì)劃從Oracle10g開(kāi)始，可以通過(guò)EXPLAIN PLAN FOR查看DDL語(yǔ)句的執(zhí)行計(jì)劃了。在9i及以前版本，Oracle只能看到DML的執(zhí)行計(jì)劃，不過(guò)從10g開(kāi)始，通過(guò)EXPLAIN PLAN FOR的方式，已經(jīng)可以看到DDL語(yǔ)句的執(zhí)行計(jì)劃了。這對(duì)于研究CREATE TABLE AS SELECT、CREATE MATERIALIZED VIEW AS SELECT以及CREATE INDEX，ALTER INDEX REBUILD等語(yǔ)句有很大的幫助。舉個(gè)簡(jiǎn)單的例子，Oracle的文檔上對(duì)于索引的建立有如下描述：The optimizer can use an existing index to build another index. This results in a much faster index build.如果看不到DDL的執(zhí)行計(jì)劃，只能根據(jù)執(zhí)行時(shí)間的長(zhǎng)短去猜測(cè)Oracle的具體執(zhí)行計(jì)劃，但是這種方法沒(méi)有足夠的說(shuō)服力。但是通過(guò)DDL的執(zhí)行計(jì)劃，就使得結(jié)果一目了然了。SQL CREATE TABLE T AS SELECT * FROM DBA_OBJECTS;表已創(chuàng)建。SQL EXPLAIN PLAN FOR2 CREATE INDEX IND_T_NAME ON T(OBJECT_NAME);已解釋。SQL SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);PLAN_TABLE_OUTPUT-Plan hash value: 3035241083-| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |-| 0 | CREATE INDEX STATEMENT | | 57915 | 3732K| 75 (2)| 00:00:01 | 1 | INDEX BUILD NON UNIQUE| IND_T_NAME | | | | | 2 | SORT CREATE INDEX | | 57915 | 3732K| | | 3 | TABLE ACCESS FULL | T | 57915 | 3732K| 41 (3)| 00:00:01 |-Note- estimated index size: 5242K bytes已選擇14行。SQL CREATE INDEX IND_T_OWNER_NAME ON T(OWNER, OBJECT_NAME);索引已創(chuàng)建。SQL EXPLAIN PLAN FOR2 CREATE INDEX IND_T_NAME ON T(OBJECT_NAME);已解釋。SQL SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);PLAN_TABLE_OUTPUT-Plan hash value: 517242163-| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |-| 0 | CREATE INDEX STATEMENT | | 57915 | 3732K| 75 (2)| 00:00:01 | 1 | INDEX BUILD NON UNIQUE| IND_T_NAME | | | | | 2 | SORT CREATE INDEX | | 57915 | 3732K| | | 3 | INDEX FAST FULL SCAN| IND_T_OWNER_NAME | | | | |-Note- estimated index size: 5242K bytes已選擇14行。SQL SET AUTOT ONSQL CREATE INDEX IND_T_NAME ON T(OBJECT_NAME);索引已創(chuàng)建。注意，查看DDL的執(zhí)行計(jì)劃需要使用EXPLAIN PLAN FOR，AUTOTRACE對(duì)于DDL是無(wú)效的。4，如何讀懂執(zhí)行計(jì)劃：Execution Plan-0 SELECT STATEMENT ptimizer=CHOOSE1 0 SORT (AGGREGATE)2 1 TABLE ACCESS (BY INDEX ROWID) OF USER_INFO3 2 NESTED LOOPS4 3 TABLE ACCESS (FULL) OF USER_NUM_TABLE5 3 INDEX (RANGE SCAN) OF PK_USER_INFO (UNIQUE)請(qǐng)問(wèn)以上執(zhí)行計(jì)劃語(yǔ)句是如何看的？語(yǔ)句的執(zhí)行順序是什么？ 讓我們來(lái)解釋一下怎么看吧,左邊的兩列數(shù)字，第一列表示這條計(jì)劃的編號(hào)，第二列是這條計(jì)劃的父計(jì)劃的編號(hào)；如果一條計(jì)劃有子計(jì)劃，那么先要執(zhí)行其子計(jì)劃;在這個(gè)例子中：從第一條編號(hào)為0的（SELECT STATEMENT ptimizer=CHOOSE）開(kāi)始，他有個(gè)子計(jì)劃1（SORT (AGGREGATE)），然后1有個(gè)子計(jì)劃2，2有子計(jì)劃3， 3 有子計(jì)劃4和5，4是3的第一個(gè)子計(jì)劃，所以先執(zhí)行4（TABLE ACCESS (FULL) OF USER_NUM_TABLE），再執(zhí)行5(INDEX (RANGE SCAN) OF PK_USER_INFO (UNIQUE)，4和5執(zhí)行完返回到其父計(jì)劃3（NESTED LOOPS），3把4和5取到的rows進(jìn)行nested loops，結(jié)果再返回到2，再到1排序，再到0select.Oracle執(zhí)行計(jì)劃解釋一相關(guān)的概念 Rowid的概念：rowid是一個(gè)偽列，既然是偽列，那么這個(gè)列就不是用戶定義，而是系統(tǒng)自己給加上的。 對(duì)每個(gè)表都有一個(gè)rowid的偽列，但是表中并不物理存儲(chǔ)ROWID列的值。不過(guò)你可以像使用其它列那樣使用它，但是不能刪除改列，也不能對(duì)該列的值進(jìn)行 修改、插入。一旦一行數(shù)據(jù)插入數(shù)據(jù)庫(kù)，則rowid在該行的生命周期內(nèi)是唯一的，即即使該行產(chǎn)生行遷移，行的rowid也不會(huì)改變。 Recursive SQL概念：有時(shí)為了執(zhí)行用戶發(fā)出的一個(gè)sql語(yǔ)句，Oracle必須執(zhí)行一些額外的語(yǔ)句，我們將這些額外的語(yǔ)句稱之為recursive calls或recursive SQL statements.如當(dāng)一個(gè)DDL語(yǔ)句發(fā)出后，ORACLE總是隱含的發(fā)出一些recursive SQL語(yǔ)句，來(lái)修改數(shù)據(jù)字典信息，以便用戶可以成功的執(zhí)行該DDL語(yǔ)句。當(dāng)需要的數(shù)據(jù)字典信息沒(méi)有在共享內(nèi)存中時(shí)，經(jīng)常會(huì)發(fā)生Recursive calls，這些Recursive calls會(huì)將數(shù)據(jù)字典信息從硬盤(pán)讀入內(nèi)存中。用戶不比關(guān)心這些recursive SQL語(yǔ)句的執(zhí)行情況，在需要的時(shí)候，ORACLE會(huì)自動(dòng)的在內(nèi)部執(zhí)行這些語(yǔ)句。當(dāng)然DML語(yǔ)句與SELECT都可能引起recursive SQL.簡(jiǎn)單的說(shuō)，我們可以將觸發(fā)器視為recursive SQL. Row Source（行源）：用在查詢中，由上一操作返回的符合條件的行的集合，即可以是表的全部行數(shù)據(jù)的集合；也可以是表的部分行數(shù)據(jù)的集合；也可以為對(duì)上2個(gè)row source進(jìn)行連接操作（如join連接）后得到的行數(shù)據(jù)集合。 Predicate（謂詞）：一個(gè)查詢中的WHERE限制條件 Driving Table（驅(qū)動(dòng)表）：該表又稱為外層表（OUTER TABLE）。這個(gè)概念用于嵌套與HASH連接中。如果該row source返回較多的行數(shù)據(jù)，則對(duì)所有的后續(xù)操作有負(fù)面影響。注意此處雖然翻譯為驅(qū)動(dòng)表，但實(shí)際上翻譯為驅(qū)動(dòng)行源（driving row source）更為確切。一般說(shuō)來(lái)，是應(yīng)用查詢的限制條件后，返回較少行源的表作為驅(qū)動(dòng)表，所以如果一個(gè)大表在WHERE條件有有限制條件（如等值限 制），則該大表作為驅(qū)動(dòng)表也是合適的，所以并不是只有較小的表可以作為驅(qū)動(dòng)表，正確說(shuō)法應(yīng)該為應(yīng)用查詢的限制條件后，返回較少行源的表作為驅(qū)動(dòng)表。在執(zhí)行 計(jì)劃中，應(yīng)該為靠上的那個(gè)row source，后面會(huì)給出具體說(shuō)明。在我們后面的描述中，一般將該表稱為連接操作的row source 1. Probed Table（被探查表）：該表又稱為內(nèi)層表（INNER TABLE）。在我們從驅(qū)動(dòng)表中得到具體一行的數(shù)據(jù)后，在該表中尋找符合連接條件的行。所以該表應(yīng)當(dāng)為大表（實(shí)際上應(yīng)該為返回較大row source的表）且相應(yīng)的列上應(yīng)該有索引。在我們后面的描述中，一般將該表稱為連接操作的row source 2. 組合索引（concatenated index）：由多個(gè)列構(gòu)成的索引，如create index idx_emp on emp（col1， col2， col3， ），則我們稱idx_emp索引為組合索引。在組合索引中有一個(gè)重要的概念：引導(dǎo)列（leading column），在上面的例子中，col1列為引導(dǎo)列。當(dāng)我們進(jìn)行查詢時(shí)可以使用“where col1 = ？ ”，也可以使用“where col1 = ？ and col2 = ？”，這樣的限制條件都會(huì)使用索引，但是“where col2 = ？ ”查詢就不會(huì)使用該索引。所以限制條件中包含先導(dǎo)列時(shí)，該限制條件才會(huì)使用該組合索引。 可選擇性（selectivity）：比較一下列中唯一鍵的數(shù)量和表中的行數(shù)，就可以判斷該列的可選擇性。 如果該列的“唯一鍵的數(shù)量/表中的行數(shù)”的比值越接近1，則該列的可選擇性越高，該列就越適合創(chuàng)建索引，同樣索引的可選擇性也越高。在可選擇性高的列上進(jìn) 行查詢時(shí)，返回的數(shù)據(jù)就較少，比較適合使用索引查詢。二oracle訪問(wèn)數(shù)據(jù)的存取方法 1） 全表掃描（Full Table Scans， FTS） 為實(shí)現(xiàn)全表掃描，Oracle讀取表中所有的行，并檢查每一行是否滿足語(yǔ)句的WHERE限制條件一個(gè)多塊讀 操作可以使一次I/O能讀取多塊數(shù)據(jù)塊（db_block_multiblock_read_count參數(shù)設(shè)定），而不是只讀取一個(gè)數(shù)據(jù)塊，這極大的減 少了I/O總次數(shù)，提高了系統(tǒng)的吞吐量，所以利用多塊讀的方法可以十分高效地實(shí)現(xiàn)全表掃描，而且只有在全表掃描的情況下才能使用多塊讀操作。在這種訪問(wèn)模 式下，每個(gè)數(shù)據(jù)塊只被讀一次。 使用FTS的前提條件：在較大的表上不建議使用全表掃描，除非取出數(shù)據(jù)的比較多，超過(guò)總量的5% 10%，或你想使用并行查詢功能時(shí)。 使用全表掃描的例子： SQL explain plan for select * from dual; Query Plan - SELECT STATEMENTCHOOSE Cost= TABLE ACCESS FULL DUAL 2） 通過(guò)ROWID的表存?。═able Access by ROWID或rowid lookup） 行的ROWID指出了該行所在的數(shù)據(jù)文件、數(shù)據(jù)塊以及行在該塊中的位置，所以通過(guò)ROWID來(lái)存取數(shù)據(jù)可以快速定位到目標(biāo)數(shù)據(jù)上，是Oracle存取單行數(shù)據(jù)的最快方法。 這種存取方法不會(huì)用到多塊讀操作，一次I/O只能讀取一個(gè)數(shù)據(jù)塊。我們會(huì)經(jīng)常在執(zhí)行計(jì)劃中看到該存取方法，如通過(guò)索引查詢數(shù)據(jù)。 使用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） 我們先通過(guò)index查找到數(shù)據(jù)對(duì)應(yīng)的rowid值（對(duì)于非唯一索引可能返回多個(gè)rowid值），然后根據(jù)rowid直接從表中得到具體的數(shù)據(jù)，這 種查找方式稱為索引掃描或索引查找（index lookup）。一個(gè)rowid唯一的表示一行數(shù)據(jù)，該行對(duì)應(yīng)的數(shù)據(jù)塊是通過(guò)一次i/o得到的，在此情況下該次i/o只會(huì)讀取一個(gè)數(shù)據(jù)庫(kù)塊。 在索引中，除了存儲(chǔ)每個(gè)索引的值外，索引還存儲(chǔ)具有此值的行對(duì)應(yīng)的ROWID值。索引掃描可以由2步組成：（1） 掃描索引得到對(duì)應(yīng)的rowid值。 （2） 通過(guò)找到的rowid從表中讀出具體的數(shù)據(jù)。每步都是單獨(dú)的一次I/O，但是對(duì)于索引，由于經(jīng)常使用，絕大多數(shù)都已經(jīng)CACHE到內(nèi)存中，所以第1步的 I/O經(jīng)常是邏輯I/O，即數(shù)據(jù)可以從內(nèi)存中得到。但是對(duì)于第2步來(lái)說(shuō)，如果表比較大，則其數(shù)據(jù)不可能全在內(nèi)存中，所以其I/O很有可能是物理I/O，這 是一個(gè)機(jī)械操作，相對(duì)邏輯I/O來(lái)說(shuō)，是極其費(fèi)時(shí)間的。所以如果多大表進(jìn)行索引掃描，取出的數(shù)據(jù)如果大于總量的5% 10%，使用索引掃描會(huì)效率下降很多。如下列所示：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 但是如果查詢的數(shù)據(jù)能全在索引中找到，就可以避免進(jìn)行第2步操作，避免了不必要的I/O，此時(shí)即使通過(guò)索引掃描取出的數(shù)據(jù)比較多，效率還是很高的 SQL explain plan for select empno from emp where empno=10;- 只查詢empno列值 Query Plan - SELECT STATEMENT CHOOSE Cost=1 INDEX UNIQUE SCAN EMP_I1 進(jìn)一步講，如果sql語(yǔ)句中對(duì)索引列進(jìn)行排序，因?yàn)樗饕呀?jīng)預(yù)先排序好了，所以在執(zhí)行計(jì)劃中不需要再對(duì)索引列進(jìn)行排序 SQL explain plan for select empno, ename from emp where empno 7876 order by empno; Query Plan - SELECT STATEMENTCHOOSE Cost=1 TABLE ACCESS BY ROWID EMP ANALYZED INDEX RANGE SCAN EMP_I1 ANALYZED 從這個(gè)例子中可以看到：因?yàn)樗饕且呀?jīng)排序了的，所以將按照索引的順序查詢出符合條件的行，因此避免了進(jìn)一步排序操作。 根據(jù)索引的類(lèi)型與where限制條件的不同，有4種類(lèi)型的索引掃描： 索引唯一掃描（index unique scan） 索引范圍掃描（index range scan） 索引全掃描（index full scan） 索引快速掃描（index fast full scan） （1） 索引唯一掃描（index unique scan） 通過(guò)唯一索引查找一個(gè)數(shù)值經(jīng)常返回單個(gè)ROWID.如果存在UNIQUE 或PRIMARY KEY 約束（它保證了語(yǔ)句只存取單行）的話，Oracle經(jīng)常實(shí)現(xiàn)唯一性掃描。 使用唯一性約束的例子： 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） 使用一個(gè)索引存取多行數(shù)據(jù)，在唯一索引上使用索引范圍掃描的典型情況下是在謂詞（where限制條件）中使用了范圍操作符（如、=、 explain plan for select empno，ename from emp where empno 7876 order by empno； Query Plan- SELECT STATEMENTCHOOSE Cost=1 TABLE ACCESS BY ROWID EMP ANALYZED INDEX RANGE SCAN EMP_I1 ANALYZED 在非唯一索引上，謂詞col = 5可能返回多行數(shù)據(jù)，所以在非唯一索引上都使用索引范圍掃描。 使用index rang scan的3種情況： （a） 在唯一索引列上使用了range操作符（ = explain plan for select empno， ename from big_emp order by empno，ename； Query Plan- SELECT STATEMENTCHOOSE Cost=26 INDEX FULL SCAN BE_IX ANALYZED （4） 索引快速掃描（index fast full scan） 掃描索引中的所有的數(shù)據(jù)塊，與 index full scan很類(lèi)似，但是一個(gè)顯著的區(qū)別就是它不對(duì)查詢出的數(shù)據(jù)進(jìn)行排序，即數(shù)據(jù)不是以排序順序被返回。在這種存取方法中，可以使用多塊讀功能，也可以使用并行讀入，以便獲得最大吞吐量與縮短執(zhí)行時(shí)間。 索引快速掃描的例子： BE_IX索引是一個(gè)多列索引： big_emp （empno，ename） SQL explain plan for select empno，ename from big_emp； Query Plan- SELECT STATEMENTCHOOSE Cost=1 INDEX FAST FULL SCAN BE_IX ANALYZED 只選擇多列索引的第2列： SQL explain plan for select ename from big_emp； Query Plan- SELECT STATEMENTCHOOSE Cost=1 INDEX FAST FULL SCAN BE_IX ANALYZED三、表之間的連接 Join是一種試圖將兩個(gè)表結(jié)合在一起的謂詞，一次只能連接2個(gè)表，表連接也可以被稱為表關(guān)聯(lián)。在后面的敘 述中，我們將會(huì)使用“row source”來(lái)代替“表”，因?yàn)槭褂胷ow source更嚴(yán)謹(jǐn)一些，并且將參與連接的2個(gè)row source分別稱為row source1和row source 2.Join過(guò)程的各個(gè)步驟經(jīng)常是串行操作，即使相關(guān)的row source可以被并行訪問(wèn)，即可以并行的讀取做join連接的兩個(gè)row source的數(shù)據(jù)，但是在將表中符合限制條件的數(shù)據(jù)讀入到內(nèi)存形成row source后，join的其它步驟一般是串行的。有多種方法可以將2個(gè)表連接起來(lái)，當(dāng)然每種方法都有自己的優(yōu)缺點(diǎn)，每種連接類(lèi)型只有在特定的條件下才會(huì) 發(fā)揮出其最大優(yōu)勢(shì)。 row source（表）之間的連接順序?qū)τ诓樵兊男视蟹浅４蟮挠绊?。通過(guò)首先存取特定的表，即將該表作為驅(qū)動(dòng)表，這樣可以先應(yīng)用某些限制條件，從而得到一個(gè) 較小的row source，使連接的效率較高，這也就是我們常說(shuō)的要先執(zhí)行限制條件的原因。一般是在將表讀入內(nèi)存時(shí)，應(yīng)用where子句中對(duì)該表的限制條件。 根據(jù)2個(gè)row source的連接條件的中操作符的不同，可以將連接分為等值連接（如WHERE A.COL3 = B.COL4）、非等值連接（WHERE A.COL3 B.COL4）、外連接（WHERE A.COL3 = B.COL4（+）。上面的各個(gè)連接的連接原理都基本一樣，所以為了簡(jiǎn)單期間，下面以等值連接為例進(jìn)行介紹。 在后面的介紹中，都已： SELECT A.COL1， B.COL2 FROM A， B WHERE A.COL3 = B.COL4； 為例進(jìn)行說(shuō)明，假設(shè)A表為Row Soruce1，則其對(duì)應(yīng)的連接操作關(guān)聯(lián)列為COL 3；B表為Row Soruce2，則其對(duì)應(yīng)的連接操作關(guān)聯(lián)列為COL 4； 連接類(lèi)型： 目前為止，無(wú)論連接操作符如何，典型的連接類(lèi)型共有3種： 排序 - - 合并連接（Sort Merge Join （SMJ） ） 嵌套循環(huán)（Nested Loops （NL） ） 哈希連接（Hash Join） 排序 - - 合并連接（Sort Merge Join， SMJ） 內(nèi)部連接過(guò)程： 1） 首先生成row source1需要的數(shù)據(jù)，然后對(duì)這些數(shù)據(jù)按照連接操作關(guān)聯(lián)列（如A.col3）進(jìn)行排序。 2） 隨后生成row source2需要的數(shù)據(jù)，然后對(duì)這些數(shù)據(jù)按照與sort source1對(duì)應(yīng)的連接操作關(guān)聯(lián)列（如B.col4）進(jìn)行排序。 3） 最后兩邊已排序的行被放在一起執(zhí)行合并操作，即將2個(gè)row source按照連接條件連接起來(lái) 下面是連接步驟的圖形表示： MERGE / SORTSORT | Row Source 1Row Source 2 如果row source已經(jīng)在連接關(guān)聯(lián)列上被排序，則該連接操作就不需要再進(jìn)行sort操作，這樣可以大大提高這種連接操作的連接速度，因?yàn)榕判蚴莻€(gè)極其費(fèi)資源的操 作，特別是對(duì)于較大的表。預(yù)先排序的row source包括已經(jīng)被索引的列（如a.col3或b.col4上有索引）或row source已經(jīng)在前面的步驟中被排序了。盡管合并兩個(gè)row source的過(guò)程是串行的，但是可以并行訪問(wèn)這兩個(gè)row source（如并行讀入數(shù)據(jù)，并行排序）。 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 排序是一個(gè)費(fèi)時(shí)、費(fèi)資源的操作，特別對(duì)于大表。基于這個(gè)原因，SMJ經(jīng)常不是一個(gè)特別有效的連接方法，但是如果2個(gè)row source都已經(jīng)預(yù)先排序，則這種連接方法的效率也是蠻高的。 嵌套循環(huán)（Nested Loops， NL） 這個(gè)連接方法有驅(qū)動(dòng)表（外部表）的概念。其實(shí)，該連接過(guò)程就是一個(gè)2層嵌套循環(huán)，所以外層循環(huán)的次數(shù)越少越好，這也就是我們?yōu)槭裁磳⑿”砘蚍祷剌^小 row source的表作為驅(qū)動(dòng)表（用于外層循環(huán)）的理論依據(jù)。但是這個(gè)理論只是一般指導(dǎo)原則，因?yàn)樽裱@個(gè)理論并不能總保證使語(yǔ)句產(chǎn)生的I/O次數(shù)最少。有時(shí) 不遵守這個(gè)理論依據(jù)，反而會(huì)獲得更好的效率。如果使用這種方法，決定使用哪個(gè)表作為驅(qū)動(dòng)表很重要。有時(shí)如果驅(qū)動(dòng)表選擇不正確，將會(huì)導(dǎo)致語(yǔ)句的性能很差、很差。 內(nèi)部連接過(guò)程： 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 從內(nèi)部連接過(guò)程來(lái)看，需要用row source1中的每一行，去匹配row source2中的所有行，所以此時(shí)保持row source1盡可能的小與高效的訪問(wèn)row source2（一般通過(guò)索引實(shí)現(xiàn)）是影響這個(gè)連接效率的關(guān)鍵問(wèn)題。這只是理論指導(dǎo)原則，目的是使整個(gè)連接操作產(chǎn)生最少的物理I/O次數(shù)，而且如果遵守這 個(gè)原則，一般也會(huì)使總的物理I/O數(shù)最少。但是如果不遵從這個(gè)指導(dǎo)原則，反而能用更少的物理I/O實(shí)現(xiàn)連接操作，那盡管違反指導(dǎo)原則吧！因?yàn)樽钌俚奈锢?I/O次數(shù)才是我們應(yīng)該遵從的真正的指導(dǎo)原則，在后面的具體案例分析中就給出這樣的例子。 在上面的連接過(guò)程中，我們稱Row source1為驅(qū)動(dòng)表或外部表。Row Source2被稱為被探查表或內(nèi)部表。 在NESTED LOOPS連接中，Oracle讀取row source1中的每一行，然后在row sourc2中檢查是否有匹配的行，所有被匹配的行都被放到結(jié)果集中，然后處理row source1中的下一行。這個(gè)過(guò)程一直繼續(xù)，直到row source1中的所有行都被處理。這是從連接操作中可以得到第一個(gè)匹配行的最快的方法之一，這種類(lèi)型的連接可以用在需要快速響應(yīng)的語(yǔ)句中，以響應(yīng)速度為 主要目標(biāo)。 如果driving row source（外部表）比較小，并且在inner row source（內(nèi)部表）上有唯一索引，或有高選擇性非唯一索引時(shí)，使用這種方法可以得到較好的效率。NESTED LOOPS有其它連接方法沒(méi)有的的一個(gè)優(yōu)點(diǎn)是：可以先返回已經(jīng)連接的行，而不必等待所有的連接操作處理完才返回?cái)?shù)據(jù)，這可以實(shí)現(xiàn)快速的響應(yīng)時(shí)間。 如果不使用并行操作，最好的驅(qū)動(dòng)表是那些應(yīng)用了where 限制條件后，可以返回較少行數(shù)據(jù)的的表，所以大表也可能稱為驅(qū)動(dòng)表，關(guān)鍵看限制條件。對(duì)于并行查詢，我們經(jīng)常選擇大表作為驅(qū)動(dòng)表，因?yàn)榇蟊砜梢猿浞掷貌?行功能。當(dāng)然，有時(shí)對(duì)查詢使用并行操作并不一定會(huì)比查詢不使用并行操作效率高，因?yàn)樽詈罂赡苊總€(gè)表只有很少的行符合限制條件，而且還要看你的硬件配置是否 可以支持并行（如是否有多個(gè)CPU，多個(gè)硬盤(pán)控制器），所以要具體問(wèn)題具體對(duì)待。 NL連接的例子： SQL explain plan for select a.dn