1,Oracle數據庫的位圖索引(Bitmap Index)確實是針對那些數值稀疏(low-cardinality，低基數)的字段，但是還應記住的一點是，它是針對那些值不經常改變的字段的。在實際應用中，如果某個字段的值需要頻繁更新，那么就不適合在它上面創(chuàng)建位圖索引。在位圖索引中，如果你更新或插入其中一條數值為N的記錄，那么相應表中數值為N的記錄（可能成百上千條）全部被Oracle鎖定，這就意味著其它用戶不能同時更新這些數值為N的記錄，其它用戶必須要等第一個用戶提交后，才能獲得鎖，更新或插入數據。
http://blog.ccidnet.com/blog-htm-do-showone-uid-4092-itemid-291252-type-blog.html

在我們的系統里，不僅不是在一個column上創(chuàng)建bitmap index，而是在多個column上聯合起來創(chuàng)建bitmap index，從而可以想見，幾乎等同于每個bitmap index entry對應的只有極少數的rowid，即只對應極少數的row，而且每個bitmap都要創(chuàng)建一個或多個bitmap segment，相應的，DML操作可能需要頻繁的lock很多rows，影響并發(fā)性（影響也需要修改同樣bitmap entry的用戶），同時，由于pctfree等存儲參數影響index空間的分配及管理，和由于數據操作導致物理地址更改從而修改index entry，擴展，鏈接bitmap index entry，頻繁修改導致的磁盤碎片，block分配鏈接等。這是空間增長和系統性能下降的部分原因。

bitmap主要用于數據倉庫，table有大量的數據并且列上基數很小（一般是column的distinct values占rows總數的1%以下，或重復出現超過100次以上，Oracle建議此時才可以把該column列為創(chuàng)建bitmap index的侯選字段），同時，還由于數據倉庫上并行訪問的事務非常少。bitmap index并不適用于OLTP業(yè)務，OLTP一般都是有大量的并發(fā)事務來修改同樣的數據。bitmap主要就是設計來為數據倉庫服務的，即應用于低基數超 級大數據量查詢服務，而且只用在where clause里包含and ,or,not,或equality queries（比如在and和or條件的查詢，在把bit轉換成rowid以前，就能很快的得到相應的boolean操作）。
http://bigboar.itpub.net/post/8411/225321

2,位圖索引占用的空間很大.一個466萬行記錄的只有兩個字段的表，占用空間約 88M,在該兩個字段上建有一個位圖索引，這個位圖索引占用空間約168M
http://bigboar.itpub.net/post/8411/225321

查看各個表(包括索引)占用空間大小的sql:
Select Segment_Name,Sum(bytes)/1024/1024 From User_Extents Group By Segment_Name

http://space.itpub.net/193161/viewspace-50292
http://www.ixdba.com/html/y2007/m05/102-bitmap-index-deadlock.html

3，Oracle強烈建立，任何一個應用程序的庫表至少需要創(chuàng)建兩個表空間，其中之一用于存儲表數據，而另一個用于存儲表索引數據。因為如果將表數據和索引數 據放在一起，表數據的I/O操作和索引的I/O操作將產生影響系統性能的I/O競爭，降低系統的響應效率。將表數據和索引數據存放在不同的表空間中（如一 個為APP_DATA，另一個為APP_IDX），并在物理層面將這兩個表空間的數據文件放在不同的物理磁盤上，就可以避免這種競爭了。
擁有獨立的表空間，就意味著可以獨立地為表數據和索引數據提供獨立的物理存儲參數，而不會發(fā)生相互影響，畢竟表數據和索引數據擁有不同的特性，而這些特性又直接影響了物理存儲參數的設定。
此外，表數據和索引數據獨立存儲，還會帶來數據管理和維護上的方面。如你在遷移一個業(yè)務數據庫時，為了降低數據大小，可以只遷出表數據的表空間，在目標數據庫中通過重建索引的方式就可以生成索引數據了。
http://blog.ccidnet.com/blog-htm-do-showone-uid-19759-itemid-341747-type-blog.html

4，B-Tree索引即normal普通索引