Oracle索引----位图索引

位图索引（bitmap index）是从Oracle7.3版本开始引入的。目前Oracle企业版和个人版都支持位图索引，但标准版不支持。位图索引是为数据仓库/即席查询环境设计的，在此所有查询要求的数据在系统实现时根本不知道。位图索引特别不适用于OLTP系统，如果系统中的数据会由多个并发会话频繁地更新，这种系统也不适用位图索引。
位图索引是这样一种结构，其中用一个索引键条目存储指向多行的指针；这与B*树结构不同，在B*树结构中，索引键和表中的行存在着对应关系。在位图索引中，可能只有很少的索引条目，每个索引条目指向多行。而在传统的B*树中，一个索引条目就指向一行。
下面假设我们要在 EMP 表的 JOB 列上创建一个位图索引，如下：
Ops$tkyte@ORA10G> create BITMAP index job_idx on emp(job);
Index created.
Oracle 在索引中存储的内容如表 11.-6 所示。

表 11.-6 Oracle 如何存储 JOB-IDX 位图索引

值/行	1	2	3	4	5	6	7	8	9	10	11	12	13	14
ANALYST	0	0	0	0	0	0	0	1	0	1	0	0	1	0
CLERK	1	0	0	0	0	0	0	0	0	0	1	1	0	1
MANAGER	0	0	0	1	0	1	1	0	0	0	0	0	0	0
PRESIDENT	0	0	0	0	0	0	0	0	1	0	0	0	0	0
SALESMAN	0	1	1	0	1	0	0	0	0	0	0	0	0	0

表11.-6显示了第8、10和13行的值为ANALYST，而第4、6和7行的值为MANAGER。在此还显示了所有行都不为null（位图索引可以存储null条目；如果索引中没有null条目，这说明表中没有null行）。如果我们想统计值为MANAGER的行数，位图索引就能很快地完成这个任务。如果我们想找出JOB为CLERK或MANAGER的所有行，只需根据索引合并它们的位图，如表11.-7所示。

表 11.-7 位 OR 的表示

值/行	1	2	3	4	5	6	7	8	9	10	11	12	13	14
CLERK	1	0	0	0	0	0	0	0	0	0	1	1	0	1
MANAGER	0	0	0	1	0	1	1	0	0	0	0	0	0	0
CLERK或MANAGER	1	0	0	1	0	1	1	0	0	0	1	1	0	1

表11.-7清楚地显示出，第1、4、6、7、11、12还有14行满足我们的要求。Oracle如下为每个键值存储位图，使得每个位置表示底层表中的一个rowid，以后如果确实需要访问行时，可以利用这个rowid进行处理。对于以下查询：
select count(*) from emp where job = 'CLERK' or job = 'MANAGER；
用位图索引就能直接得出答案。另一方面，对于以下查询：
select * from emp where job = 'CLERK' or job = 'MANAGER'
则需要访问表。在此 Oracle 会应用一个函数把位图中的第 i 位转换为一个 rowid，从而可用于访问表。

什么情况下应该使用位图索引？
位图索引对于相异基数（distinctcard inality）低的数据最为合适（也就是说，与整个数据集的基数相比，这个数据只有很少几个不同的值）。对此做出量化是不太可能的——换句话说，很难定义低相异基数到底是多大。在一个有几千条记录的数据集中，2就是一个低相异基数，但是在一个只有两行的表中，2就不能算是低相异基数了。而在一个有上千万或上亿条记录的表中，甚至100,000都能作为一个低相异基数。所以，多大才算是低相异基数，这要相对于结果集的大小来说。这是指，行集中不同项的个数除以行数应该是一个很小的数（接近于0）。例如，GENDER列可能取值为M、F和NULL。如果一个表中有20,000条员工记录，那么3/20000=0.00015。类似地，如果有100,000个不同的值，与11.,000,000条结果相比，比值为0.01，同样这也很小（可算是低相异基数）。这些列就可以建立位图索引。它们可能不适合建立B*树索引，因为每个值可能会获取表中的大量数据（占很大百分比）。如前所述，B*树索引一般来讲应当是选择性的。与之相反，位图索引不应是选择性的，一般来讲它们应该“没有选择性“。
不过，在某些情况下，位图并不合适。位图索引在读密集的环境中能很好地工作，但是对于写密集的环境则极不适用。原因在于，一个位图索引键条目指向多行。如果一个会话修改了所索引的数据，那么在大多数情况下，这个索引条目指向的所有行都会被锁定。Oracle无法锁定一个位图索引条目中的单独一位；而是会锁定这个位图索引条目。倘若其他修改也需要更新同样的这个位图索引条目，就会被“关在门外“。这样将大大影响并发性，因为每个更新都有可能锁定数百行，不允许并发地更新它们的位图列。在此不是像你所想的那样锁定每一行，而是会锁定很多行。位图存储在块（chunk）中，所以，使用前面的EMP例子就可以看到，索引键ANALYST在索引中出现了多次，每一次都指向数百行。更新一行时，如果修改了JOB列，则需要独占地访问其中两个索引键条目：对应老值的索引键条目和对应新值的索引键条目。这两个条目指向的数百行就不允许其他会话修改，直到UPDATE提交。