谨慎使用位图索引及其原因（原）

在这里，我将为大家介绍一下位图索引的原理，及其使用方法。

对于位图索引的概念，我就不讲述了，请查看ORACLE REFERENCE。

 

最浅显的认识是，位图索引适用于低基数的列，比如说性别列，数据仓库中的维表的主键，等等。理论上来说，他们都适合应用位图索引。但是这并不是使用位图索引唯一的条件。滥用位图索引会导致严重的错误，而且这些错误往往是很隐蔽的，不易被发现的错误。

 

位图索引的原理：

   采用位图索引，一个键指向多行，有时候是数以百计甚至更多。如果更新了一个位图索引键，那么这个键指向的数以百计的记录会与你实际更新的那一行一同被锁定。

我以一个表为例：

create table t(sex char);

create bitmap index t_index on t(sex);

假设表中有100万条数据，50万条F，50万M。

 

所以，如果有人插入一行记录(sex的值是F)，就会锁定位图表中的F键，而这会有效的同时锁定另外50W条值为F的记录，此时，想要读这个表并处理记录的进程就无法将F记录修改为M记录。原因是，想要把这个列从F更新为M,需要锁定同一个位图索引键，所以，想要在这个表中插入新记录的其他会话也会阻塞，因为它们同样想对这个位图索引键锁定，简单来说，开发人员实现了一个结构：每次最多只允许一个人插入或更新，这对于OLTP系统是致命的。

 

比如执行并不commit：

insert into t value('F');

 

现在我在另一个sql*plus会话中执行下面命令：

insert into t value('F');

 

这条语句会“挂起”，直到在第一个阻塞会话中commit；

 

总结：

在OLTP的系统中，即使是sex这样的字段，千万不要使用BITMAP索引，bitmap索引最好的适用于是在OLAP应用中对事实表的外键使用（因为DW的应用对事实表不会有任何UPDATE，delete，insert操作）事实上，用的最多的是BITMAP JOIN索引。即使是地区维，时间维，这样看似重复数据不多的情况，其实维表的数据量对于海量的事实表来说是微乎其微的，使用BITMAP索引，能够有效的提高查询效率。

bitmap index 在数据仓库中的应用，请查看：

 

有人会问：像sex这样的字段，到底是否需要使用索引？这一点，我的建议是不用使用索引，因为表中大部分都是重复的M和F，但是如果有频繁的类似COUNT的统计操作，使用传统的B-TREE索引是可以提高performance的。