oracle提供了大量索引選項。知道在給定條件下使用哪個選項對於乙個應用程式的效能來說非常重要。乙個錯誤的選擇可能會引發死鎖,並導致資料庫效能急劇下降或程序終止。而如果做出正確的選擇,則可以合理使用資源,使那些已經執行了幾個小時甚至幾天的程序在幾分鐘得以完成,這樣會使您立刻成為一位英雄。這篇文章就將簡單的討論每個索引選項。主要有以下內容:
[1] 基本的索引概念
查詢dba_indexes檢視可得到表中所有索引的列表,注意只能通過user_indexes的方法來檢索模式(schema)的索引。訪問user_ind_columns檢視可得到乙個給定表中被索引的特定列。
[2] 組合索引
當某個索引包含有多個已索引的列時,稱這個索引為組合(concatented)索引。在 oracle9i引入跳躍式掃瞄的索引訪問方法之前,查詢只能在有限條件下使用該索引。比如:表emp有乙個組合索引鍵,該索引包含了empno、 ename和deptno。在oracle9i之前除非在where之句中對第一列(empno)指定乙個值,否則就不能使用這個索引鍵進行一次範圍掃瞄。
特別注意:在oracle9i之前,只有在使用到索引的前導索引時才可以使用組合索引!
[3] oracle rowid
通過每個行的rowid,索引oracle提供了訪問單行資料的能力。rowid其實就是直接指向單獨行的線路圖。如果想檢查重複值或是其他對rowid本身的引用,可以在任何表中使用和指定rowid列。
[4] 限制索引
限制索引是一些沒有經驗的開發人員經常犯的錯誤之一。在sql中有很多陷阱會使一些索引無法使用。下面討論一些常見的問題:
4.1 使用不等於操作符(<>、!=) 下面的查詢即使在cust_rating列有乙個索引,查詢語句仍然執行一次全表掃瞄。 select cust_id,cust_name from customers where cust_rating <> 'aa'; 把上面的語句改成如下的查詢語句,這樣,在採用基於規則的 優化器而不是基於代價的優化器(更智慧型)時,將會使用索引。 select cust_id,cust_name from customers where cust_rating < 'aa' or cust_rating > 'aa'; 特別注意:通過把不等於操作符改成or條件,就可以使用索引,以避免全表掃瞄。4.2 使用is null 或is not null
使用is null 或is not null同樣會限制索引的使用。因為null值並沒有被定義。在sql語句中使用null會有很多的麻煩。因此建議開發人員在建表時,把需要索引的列設成not null。如果被索引的列在某些行中存在null值,就不會使用這個索引(除非索引是乙個位圖索引,關於位圖索引在稍後在詳細討論)。
4.3 使用函式
如果不使用基於函式的索引,那麼在sql語句的where子句中對存在索引的列使用函式時,會使優化器忽略掉這些索引。 下面的查詢不會使用索引(只要它不是基於函式的索引)
select empno,ename,deptno from emp where trunc(hiredate)='01-may-81'; 把上面的語句改成下面的語句,這樣就可以通過索引進行查詢。 select empno,ename,deptno from emp where hiredate<(to_date('01-may-81')+0.9999); 4.4 比較不匹配的資料型別 比較不匹配的資料型別也是比較難於發現的效能問題之一。 注意下面查詢的例子,account_number是乙個varchar2型別, 在account_number欄位上有索引。下面的語句將執行全表掃瞄。 select bank_name,address,city,state,zip from banks where account_number = 990354; oracle可以自動把where子句變成to_number(account_number)=990354,這樣就限制了 索引的使用,改成下面的查詢就可以使用索引: select bank_name,address,city,state,zip from banks where account_number ='990354'; 特別注意:不匹配的資料型別之間比較會讓oracle自動限制索引的使用, 即便對這個查詢執行explain plan也不能讓您明白為什麼做了一次「全表掃瞄」。[5] 選擇性
使用user_indexes檢視,該檢視中顯示了乙個distinct_keys列。比較一下唯一鍵的數量和表中的行數,就可以判斷索引的選擇性。選擇性越高,索引返回的資料就越少。
[6] 群集因子(clustering factor)
clustering factor位於user_indexes檢視中。該列反映了資料相對於已索引的列是否顯得有序。如果clustering factor列的值接近於索引中的樹葉塊(leaf block)的數目,表中的資料就越有序。如果它的值接近於表中的行數,則表中的資料就不是很有序。
[7] 二元高度(binary height)
索引的二元高度對把rowid返回給使用者程序時所要求的i/o量起到關鍵作用。在對乙個索引進行分析後,可以通過查詢dba_indexes的b- level列檢視它的二元高度。二元高度主要隨著表的大小以及被索引的列中值的範圍的狹窄程度而變化。索引上如果有大量被刪除的行,它的二元高度也會增加。更新索引列也類似於刪除操作,因為它增加了已刪除鍵的數目。重建索引可能會降低二元高度。
[8] 快速全域性掃瞄
在oracle7.3後就可以使用快速全域性掃瞄(fast full scan)這個選項。這個選項允許oracle執行乙個全域性索引掃瞄操作。快速全域性掃瞄讀取b-樹索引上所有樹葉塊。初始化檔案中的 db_file_multiblock_read_count引數可以控制同時被讀取的塊的數目。
[9] 跳躍式掃瞄
從oracle9i開始,索引跳躍式掃瞄特性可以允許優化器使用組合索引,即便索引的前導列沒有出現在where子句中。索引跳躍式掃瞄比全索引掃瞄要快的多。下面的程式清單顯示出效能的差別:
create index skip1 on emp5(job,empno); index created. select count(*) from emp5 where empno=7900; elapsed:00:00:03.13 execution plan 0 select statement optimizer=choose(cost=4 card=1 bytes=5) 1 0 sort(aggregate) 2 1 index(fast full scan) of 'skip1'(non-unique) statistics 6826 consistent gets 6819 physical reads select /*+ index(emp5 skip1)*/ count(*) from emp5 where empno=7900; elapsed:00:00:00.56 execution plan 0 select statement optimizer=choose(cost=6 card=1 bytes=5) 1 0 sort(aggregate) 2 1 index(skip scan) of 'skip1'(non-unique) statistics 21 consistent gets 17 physical reads[10] 索引的型別 b-樹索引 位圖索引 hash索引 索引編排表 反轉鍵索引 基於函式的索引 分割槽索引 本地和全域性索引
Oracle索引原理
乙個b樹索引只有乙個根節點,它實際就是位於樹的最頂端的分支節點。可以用下圖一來描述b樹索引的結構。其中,b表示分支節點,而l表示葉子節點。對於分支節點塊 包括根節點塊 來說,其所包含的索引條目都是按照順序排列的 預設是公升序排列,也可以在建立索引時指定為降序排列 每 個索引條目 也可以叫做每條記錄 ...
Oracle索引原理
乙個b樹索引只有乙個根節點,它實際就是位於樹的最頂端的分支節點。可以用下圖一來描述b樹索引的結構。其中,b表示分支節點,而l表示葉子節點。對於分支節點塊 包括根節點塊 來說,其所包含的索引條目都是按照順序排列的 預設是公升序排列,也可以在建立索引時指定為降序排列 每 個索引條目 也可以叫做每條記錄 ...
ORACLE 索引原理
乙個b樹索引只有乙個根節點,它實際就是位於樹的最頂端的分支節點。可以用下圖一來描述b樹索引的結構。其中,b表示分支節點,而l表示葉子節點。對於分支節點塊 包括根節點塊 來說,其所包含的索引條目都是按照順序排列的 預設是公升序排列,也可以在建立索引時指定為降序排列 每個索引條目 也可以叫做每條記錄 都...