邏輯上: Single column 單行索引 Concatenated 多行索引 Unique 唯一索引 NonUnique 非唯一索引 Function-based函數(shù)索引 Domain 域索引
物理上: Partitioned 分區(qū)索引 NonPartitioned 非分區(qū)索引 B-tree: Normal 正常型B樹 Rever Key 反轉(zhuǎn)型B樹 Bitmap 位圖索引
索引結(jié)構(gòu): B-tree: 適合與大量的增、刪、改(OLTP); 不能用包含OR操作符的查詢; 適合高基數(shù)的列(唯一值多) 典型的樹狀結(jié)構(gòu); 每個結(jié)點都是數(shù)據(jù)塊; 大多都是物理上一層、兩層或三層不定,邏輯上三層; 葉子塊數(shù)據(jù)是排序的,從左向右遞增; 在分支塊和根塊中放的是索引的范圍; Bitmap: 適合與決策支持系統(tǒng); 做UPDATE代價非常高; 非常適合OR操作符的查詢; 基數(shù)比較少的時候才能建位圖索引; 樹型結(jié)構(gòu): 索引頭 開始ROWID,結(jié)束ROWID(先列出索引的最大范圍) BITMAP 每一個BIT對應(yīng)著一個ROWID,它的值是1還是0,如果是1,表示著BIT對應(yīng)的ROWID有值;
B*tree索引的話通常在訪問小數(shù)據(jù)量的情況下比較適用,比如你訪問不超過表中數(shù)據(jù)的5%,當(dāng)然這只是個相對的比率,適用于一般的情況。bitmap的話在數(shù)據(jù)倉庫中使用較多,用于低基數(shù)列,比如性別之類重復(fù)值很多的字段,基數(shù)越小越好。
索引就好象一本字典的目錄。憑借字典的目錄,我們可以非常迅速的找到我們所需要的條目。數(shù)據(jù)庫也是如此。憑借Oracle數(shù)據(jù)庫的索引,相關(guān)語句可以迅速的定位記錄的位置,而不必去定位整個表。
雖然說,在表中是否創(chuàng)建索引,不會影響到Oracle數(shù)據(jù)庫的使用,也不會影響數(shù)據(jù)庫語句的使用。這就好像即使字典沒有目錄的話,用戶仍然可以使用它一樣??墒牵糇值錄]有目錄,那么可想而知,用戶要查某個條目的話,其不得不翻遍整本字典。數(shù)據(jù)庫也是如此。若沒有建立相關(guān)索引的話,則數(shù)據(jù)庫在查詢記錄的時候,不得不去查詢整個表。當(dāng)表中的記錄比較多的時候,其查詢效率就會很低。所以,合適的索引,是提高數(shù)據(jù)庫運行效率的一個很好的工具。
不過,并不是說表上的索引越多越好。過之而不及。故在數(shù)據(jù)庫設(shè)計過程中,還是需要為表選擇一些合適的索引。寧缺勿濫,這是建立索引時的一個遵循標(biāo)準(zhǔn)。在理論上,雖然一個表可以設(shè)置無限的索引。但是,數(shù)據(jù)庫管理員需要知道,表中的索引越多,維護(hù)索引所需要的開銷也就越大。每當(dāng)數(shù)據(jù)表中記錄有增加、刪除、更新變化的時候,數(shù)據(jù)庫系統(tǒng)都需要對所有索引進(jìn)行更新。故數(shù)據(jù)庫表中的索引絕對不是多多益善。具體來說,在索引建立上,筆者對大家有如下建議。
建議一:在基數(shù)小的字段上要善于使用位圖索引。
基數(shù)是位圖索引中的一個基本的定義,它是指數(shù)據(jù)庫表中某個字段內(nèi)容中不重復(fù)的數(shù)值。如在員工信息表中的性別字段,一般就只有男跟女兩個值,所以,其基數(shù)為2;婚姻狀況字段的話,則其只有已婚、未婚、離婚三種狀態(tài),其基數(shù)就為3;民族一覽內(nèi)也是只有有限的幾個值。
對于要查詢基數(shù)小的字段,如現(xiàn)在用戶想查找所有婚姻狀況為“已婚”的“女性”時,利用位圖索引可以提高查詢的效率。這主要是因為標(biāo)準(zhǔn)索引是通過在索引中保存排序過的索引列以及對應(yīng)的ROWID來實現(xiàn)的。若我們在基數(shù)小的列上建立標(biāo)準(zhǔn)索引的話,則其會返回大量的記錄。
而當(dāng)我們在創(chuàng)建位圖索引的時候,在Oracle會對整個表進(jìn)行掃描,并且會為索引列的每個取值建立一個位圖。若內(nèi)容相同,則在位圖上會以一個相同的數(shù)字表示。此時,若這個字段的基數(shù)比較小的話,則若需要實現(xiàn)對整個字段的查詢的話,效率就會非常的高。因為此時,數(shù)據(jù)庫只要位圖中數(shù)字相同的內(nèi)容找出來即可。
除了在數(shù)據(jù)表某列基數(shù)比較小的情況下,采用位圖索引外,我們往往在一些特殊的情況下,也會建議采用位圖索引。最常見的情況是,在Where限制條件中,若我們多次采用AND或者OR條件時,也建議采用位圖索引。因為當(dāng)一個查詢飲用了一些部署了位圖索引的列的時候,這些位圖可以很方便的與AND或者Or 運算符操作結(jié)合以快速的找出用戶所需要的記錄。
但是,這里要注意,不是在條件語句中包含運算符的時候,采用位圖索引都能夠提供比較高的效率。一般來說,只有AND 或者OR運算符的時候,位圖索引才會比較具有優(yōu)勢。若此時用戶采用大于號或者不等于號作為條件語句中的限制條件的時候,則往往采用標(biāo)準(zhǔn)索引具有更大的優(yōu)勢。
所以,筆者在數(shù)據(jù)庫設(shè)置中,一般只有在三種情況下才采用位圖索引。一是列的基數(shù)比較小,而有可能需要根據(jù)這些字段的內(nèi)容查找相關(guān)的記錄;二是在條件語句中,用到了AND或者OR運算符的時候。除了這兩種情況外,最好能夠采用其他適合的索引。第三種情況是,需要用到NULL作為查詢的限制條件。因為標(biāo)準(zhǔn)查詢一般情況下,會忽略所有的NULL值列。也就是說,若需要查詢“所有沒有身份證號碼”的員工的信息的時候,標(biāo)準(zhǔn)索引并不能夠起到加速查詢速度的作用。此時,就需要采用位圖索引。因為位圖索引會記錄相關(guān)的NULL值列信息。
建議二:創(chuàng)建索引的一些限制條件。
并不說,表或者列建立的索引越多越好。相反,索引建的越多,有時會反而會影響數(shù)據(jù)庫運行的整體性能。所以,在建立索引的時候,仍然會有一些限制條件。
一是不要對一些記錄內(nèi)容比較少的表建立索引。在一個應(yīng)用系統(tǒng)設(shè)計的時候,如設(shè)計一個ERP系統(tǒng)的數(shù)據(jù)庫,其雖然有幾千張表。但是,并不是每張表都有大量記錄的。相反,其中有近一半左右的數(shù)據(jù)表,可能其存儲的數(shù)據(jù)不會超過百條。如員工登陸帳戶密碼表、企業(yè)部門信息表等等。對于這些記錄內(nèi)容比較少的表,我們建立最好不要為其建立索引。無論是表上的,還是字段上,都不要建立索引。
二是若表中的內(nèi)容比較大,但是,這個表基本上不怎么查詢的時候,則只需要在表上建立索引即可;而不需要在字段上建立索引。如現(xiàn)在在ERP系統(tǒng)中,有一張表是“AD_Table”。其存儲的是這個數(shù)據(jù)庫中相關(guān)表的信息。這張表只有在數(shù)據(jù)庫設(shè)計的時候才會用到。故這張表中的記錄雖然比較多,但是由于用戶用的比較少,所以,一般沒有必要為這張表建立列級別上的索引。而直接用表索引來代替。
三是在一些NULL字段上,要根據(jù)實際情況來判斷是否要建立索引。如現(xiàn)在有一張人事檔案的表格,其上面有兩個字段,分別為“身份證號碼”與“地區(qū)”。有時會為了某個原因,企業(yè)需要所有員工都在系統(tǒng)中登記他們的身份證號碼,以方便他們辦工資卡、社會保險等等。所以人事管理可能需要經(jīng)常的查詢系統(tǒng),看看有沒有沒有身份證號碼的員工信息。此時,就需要利用條件“IS NULL”來查詢我們所需要的記錄。故為了提高查詢效率,若某個記錄可能為空,并且經(jīng)常需要以NULL為條件進(jìn)行查詢的時候,則最好給這個字段添加一個索引,并且最好建立位圖索引。相反,若雖然可能會以NULL這個條件作為查詢的限制語句,但是,用的不是很多的時候,則就沒有必要為其建立索引。
建議三:多表連接查詢的索引設(shè)計。
如現(xiàn)在有一個人事管理系統(tǒng)。人事經(jīng)理想知道員工的社保繳納情況。他需要知道員工的姓名、職務(wù)、戶籍性質(zhì)(農(nóng)民戶口跟居民戶口費用不一樣)、繳納的情況等等。但是,這些信息包含在不同的表中。因為為了提高數(shù)據(jù)庫的性能,在表中存儲的可能只是某些序號,而不是具體的內(nèi)容。如在社保表中,存儲的是員工對應(yīng)的編號,而不是員工的名字。所以,要得到這份報表的話,就可能需要關(guān)聯(lián)員工基本信息表、公司組織結(jié)構(gòu)表等表格,才能夠查詢到用戶所需要的內(nèi)容。
為此,就需要利用Join語句,把這些表格關(guān)聯(lián)起來。為了提高數(shù)據(jù)庫的查詢效率,這些用來關(guān)聯(lián)的字段,最好能夠建立索引。這可以顯著的提高查詢的速度。
建議四:在表的更新速度與查詢速度之間尋求一個平衡點。
眾所周知,索引本身并不影響數(shù)據(jù)庫的使用,其主要是為了提高數(shù)據(jù)庫的查詢效率。但是,由于當(dāng)數(shù)據(jù)庫的表中的數(shù)據(jù)更新的時候,包括記錄的增加、刪除、更改等等,都會對雖有的索引進(jìn)行更新。
很明顯,索引雖然可以提高查詢速度。但是,也會對一些表的更新操作產(chǎn)生不良的影響。當(dāng)在表中建立的索引越多,這個不利影響也會越大。故數(shù)據(jù)庫管理員在設(shè)置索引的時候,還需要注意,在這兩個之間需要一個均衡點。
按照一般的理論來說,當(dāng)某個表多數(shù)用來查詢、更新相對來說比較上的話,則要多多采用索引。相反,當(dāng)某個表記錄更新居主導(dǎo),查詢相對來說比較少的話,則不要建立太多的索引,避免對更新的速度差生不利影響。
在實際工作中,若某個表頻繁的被視圖所調(diào)用的話,則最好就好設(shè)置比較多的索引了。
|