Oracle索引原理

wuyuanyong發表於2010-06-24

Oracle索引原理

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

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索引
索引編排表
反轉鍵索引
基於函式的索引
分割槽索引
本地和全域性索引

本文出自:

熱點文章

[@more@]
計算索引的大小
從8.0開始,ORACLE把 num_rows 加入 dba_indexes 表. 之前,我們需要將dba_indexes 和 dba_tables 做一個聯合查詢才能得到一個索引的num_rows 。在執行這個操作時,我們沒有考慮到索引值可能為空而沒有被包括在內的情況。索引的行數有可能會小於或等於表的行數。因此,我們所新增的區域所佔用的空間大小就最終決定了索引的空間大小。

執行下邊的語句,可以檢視當前表TASK的索引用到的空間:

select a.owner,a.index_name,a.leaf_blocks,a.num_rows
from dba_indexes a
where a.owner not in ('SYS','SYSTEM')
and a.index_type!='BITMAP'
and a.last_analyzed is not null
and a.table_name = 'TASK';

OWNER INDEX_NAME LEAF_BLOCKS NUM_ROWS
ORADBA TASK_APPT_FK 65 23771
ORADBA TASK_CENTER_FK 99 45975
ORADBA TASK_CLIENT_FK 101 45975
ORADBA TASK_ENC_FK 117 45975
ORADBA TASK_TYPE_FK 74 45975
ORADBA TASK_DT_REQ 84 45975

看這裡,我們查出當前索引 task_appt_ft 的23771行 都在65 個塊中,可能有不用的空間在這些 65個塊中,但是我們稍後將會處理。這意味著,我們在每個塊中大約擁有366行 (23,771/65) 。使用在上一章--B-Tree 大小中我們提到的邏輯,如果我們有超過 366個塊,那麼我們會有一個branch blocks。 但是這個索引只有這個root block。而索引的真正需求是65 leaf_blocks+1 root block =66個塊,正像它目前被定義的一樣。

那麼索引到底需要多大空間呢?我們可以從dba_segments 找到答案,讓我們把它加入到我們的查詢中;

select a.owner,a.index_name,a.leaf_blocks,a.num_rows,b.blocks
from dba_indexes a
,dba_segments b
where a.owner not in ('SYS','SYSTEM')
and a.index_type!='BITMAP'
and a.last_analyzed is not null
and a.table_name = 'TASK'
and a.owner = b.owner
and a.index_name = b.segment_name;

OWNER INDEX_NAME LEAF_BLOCKS NUM_ROWS BLOCKS
ORADBA TASK_APPT_FK 65 23771 175
ORADBA TASK_CENTER_FK 99 45975 145
ORADBA TASK_CLIENT_FK 101 45975 205
ORADBA TASK_ENC_FK 117 45975 215
ORADBA TASK_TYPE_FK 74 45975 195
ORADBA TASK_DT_REQ 84 45975 86

我們會發現 task_appt_fk 索引需要 66個塊,但是現在卻佔有了175個塊。因此,如果我們按照正確的大小重新建立索引,我們可以釋放109個塊。而所有的這些則是建立於先前執行的沒有丟失任何使用者的統計的基礎之上的。我可以選擇一天中的任何時間。

重新指定大小和碎片整理的邏輯步驟:

那麼,我們使用這些新的發現以做得更好?這裡有一個最好的案例:我們製作一個完整的表空間時,可以使重新設定大小和整理表空間碎片同時進行。具體步驟如下:

• 根據dba_indexes索引的大小,在不同得表空間中重新建立索引。這會去掉索引中任何被刪除的空間。
• Coalesce表空間
• 透過分析這些索引得到基於分鐘的統計
• 把索引重新建立回index tablespace
出自:http://www.itpub.net/thread-760206-1-1.html

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/13879334/viewspace-1034627/,如需轉載,請註明出處,否則將追究法律責任。

相關文章