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)
使用索引范圍掃描的例子:
在非唯一索引上,謂詞col = 5可能返回多行數據,所以在非唯一索引上都使用索引范圍掃描。
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]
(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(+))。上面的各個連接的連接原理都基本一樣,所以為了簡單期間,下面以等值連接為例進行介紹。
在後面的介紹中,都已:
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
/\
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都已經預先排序,則這種連接方法的效率也是蠻高的。
嵌套循環(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,deptQuery 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行結果。