bitmap位图索引

1, Oracle数据库的位图索引(Bitmap Index)确实是针对那些数值稀疏(low-cardinality，低基数)的字段，但是还应记住的一点是，它是针对那些值不经常改变的字段的。在实际应用中，如果某个字段的值需要频繁更新，那么就不适合在它上面创建位图索引。在位图索引中，如果你更新或插入其中一条数值为N的记录，那么相应表中数值为N的记录（可能成百上千条）全部被Oracle锁定，这就意味着其它用户不能同时更新这些数值为N的记录，其它用户必须要等第一个用户提交后，才能获得锁，更新或插入数据。
http://blog.ccidnet.com/blog-htm-do-showone-uid-4092-itemid-291252-type-blog.html

在我们的系统里，不仅不是在一个column上创建bitmap index，而是在多个column上联合起来创建bitmap index，从而可以想见，几乎等同于每个bitmap index entry对应的只有极少数的rowid，即只对应极少数的row，而且每个bitmap都要创建一个或多个bitmap segment，相应的，DML操作可能需要频繁的lock很多rows，影响并发性（影响也需要修改同样bitmap entry的用户），同时，由于pctfree等存储参数影响index空间的分配及管理，和由于数据操作导致物理地址更改从而修改index entry，扩展，链接bitmap index entry，频繁修改导致的磁盘碎片，block分配链接等。这是空间增长和系统性能下降的部分原因。

bitmap主要用于数据仓库，table有大量的数据并且列上基数很小（一般是column的distinct values占rows总数的1%以下，或重复出现超过100次以上，Oracle建议此时才可以把该column列为创建bitmap index的侯选字段），同时，还由于数据仓库上并行访问的事务非常少。bitmap index并不适用于OLTP业务，OLTP一般都是有大量的并发事务来修改同样的数据。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强烈建立，任何一个应用程序的库表至少需要创建两个表空间，其中之一用于存储表数据，而另一个用于存储表索引数据。因为如果将表数据和索引数 据放在一起，表数据的I/O操作和索引的I/O操作将产生影响系统性能的I/O竞争，降低系统的响应效率。将表数据和索引数据存放在不同的表空间中（如一 个为APP_DATA，另一个为APP_IDX），并在物理层面将这两个表空间的数据文件放在不同的物理磁盘上，就可以避免这种竞争了。
拥有独立的表空间，就意味着可以独立地为表数据和索引数据提供独立的物理存储参数，而不会发生相互影响，毕竟表数据和索引数据拥有不同的特性，而这些特性又直接影响了物理存储参数的设定。
此外，表数据和索引数据独立存储，还会带来数据管理和维护上的方面。如你在迁移一个业务数据库时，为了降低数据大小，可以只迁出表数据的表空间，在目标数据库中通过重建索引的方式就可以生成索引数据了。
http://blog.ccidnet.com/blog-htm-do-showone-uid-19759-itemid-341747-type-blog.html

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