位图索引（bitmap index）是从Oracle7.3版本开始引入的。目前Oracle企业版和个人版都支持位图索引，但标准版不支持。位图索引是为数据仓库/即席查询环境设计的，在此所有查询要求的数据
位图索引（bitmap index）是从Oracle7.3版本开始引入的。目前Oracle企业版和个人版都支持位图索引，但标准版不支持。位图索引是为数据仓库/即席查询环境设计的，在此所有查询要求的数据在系统实现时根本不知道。位图索引特别不适用于OLTP系统，如果系统中的数据会由多个并发会话频繁地更新，这种系统也不适用位图索引。
位图索引是这样一种结构，其中用一个索引键条目存储指向多行的指针；这与B*树结构不同，在B*树结构中，索引键和表中的行存在着对应关系。在位图索引中，可能只有很少的索引条目，每个索引条目指向多行。而在传统的B*树中，一个索引条目就指向一行。
下面假设我们要在EMP表的JOB列上创建一个位图索引，如下：
system@ORCL>create BITMAP index job_idx on emp(job);索引已创建。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进行处理。对于以下查询：
system@ORCL>select count(*) from emp where job = 'CLERK' or job = 'MANAGER'; COUNT(*)---------- 7用位图索引就能直接得出答案。另一方面，对于以下查询：
system@ORCL>select * from emp where job = 'CLERK' or job = 'MANAGER'; EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO---------- ---------- --------- ---------- -------------- ---------- -------------------- 7369 SMITH CLERK 7902 17-12月-80 32387 20 7566 JONES MANAGER 7839 02-4月 -81 34562 20 7698 BLAKE MANAGER 7839 01-5月 -81 34437 30 7782 CLARK MANAGER 7839 09-6月 -81 34037 10 7876 ADAMS CLERK 7788 23-5月 -87 34321.35 20 7900 JAMES CLERK 7698 03-12月-81 32537 30 7934 MILLER CLERK 7782 23-1月 -82 32887 10已选择7行。则需要访问表。在此Oracle会应用一个函数把位图中的第i位转换为一个rowid，从而可用于访问表。
3.1什么情况下应该使用位图索引？
位图索引对于相异基数（distinct cardinality）低的数据最为合适（也就是说，与职工数据集的基数相比，这个数据只有很少几个不同的值）。对此做出量化是不太可能的——换句话说，很难定义低相异基数到底是多大。在一个有几千条记录的数据集中，2就是一个低相异基数，但是在一个只有两行的表中，2就不能算是低相异基数了。而在一个有上千万或上亿条记录的表中，甚至100,000都能作为一个低相异基数。所以，多大才算是低相异基数，这要相对于结果集的大小来说。这是指，行集中不同项的个数除以行数应该是一个很小的数（接近于0）。例如，GENDER列可能取值为M、F和NULL。如果一个表中有20,000条员工记录，那么3/20000=0.00015。类似地，如果有100,000个不同的值，与11.,000,000条结果相比，比值为0.01，同样这也很小（可算是低相异基数）。这些列就可以建立位图索引。它们可能不适合建立B*树索引，因为每个值可能会获取表中的大量数据（占很大百分比）。如前所述，B*树索引一般来讲应当是选择性的。与之相反，位图索引不应是选择性的，一般来讲它们应该“没有选择性“。
如果有大量即席查询，特别是查询以一种即席方式引用了多列或者会生成诸如COUNT之类的聚合，在这样的环境中，位图索引就特别有用。例如，假设你有一个很大的表，其中有3列：GENDER、LOCATION和AGE_GROUP。在这个表中，GENDER只有两个可取值：M或F，LOCATION可取值为11.50，AGE_GROUP是一个代码，分别表示11. and under（11.及以下）、11.-25、26-30、31-40和41 and over（41及以上）。
在一个数据仓库或支持多个即席SQL查询的大型报告系统中，能同时合理地使用尽可能多的索引确实非常有用。
位图索引在读密集的环境中能很好地工作，但是对于写密集的环境则极不适用。原因在于，一个位图索引键条目指向多行。如果一个会话修改了所索引的数据，那么在大多数情况下，这个索引条目指向的所有行都会被锁定。Oracle无 法锁定一个位图索引条目中的单独一位；而是会锁定这个位图索引条目。倘若其他修改也需要更新同样的这个位图索引条目，就会被“关在门外“。这样将大大影响 并发性，因为每个更新都有可能锁定数百行，不允许并发地更新它们的位图列。在此不是像你所想的那样锁定每一行，而是会锁定很多行。
位图联结索引 （bitmap join index）
它允许使用另外某个表的列对一个给定表建立索引。实际上，这就允许对一个索引结构（而不是表本身）中的数据进行逆规范化。
考虑简单的EMP表和DEPT表。EMP有指向DEPT的一个外键（DEPTNO列）。DEPT表有一个DNAME属性（部门名）。
运行的查询如下所示：
system@ORCL>select count(*) 2 from emp, dept 3 where emp.deptno = dept.deptno 4 and dept.dname = 'SALES' 5 / COUNT(*)---------- 6system@ORCL>select emp.* 2 from emp, dept 3 where emp.deptno = dept.deptno 4 and dept.dname = 'SALES' 5 / EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO---------- ---------- --------- ---------- -------------- ---------- -------------------- 7499 ALLEN SALESMAN 7698 20-2月 -81 33187 300 30 7521 WARD SALESMAN 7698 22-2月 -81 32837 500 30 7654 MARTIN SALESMAN 7698 28-9月 -81 32837 1400 30 7698 BLAKE MANAGER 7839 01-5月 -81 34437 30 7844 TURNER SALESMAN 7698 08-9月 -81 33087 0 30 7900 JAMES CLERK 7698 03-12月-81 32537 30已选择6行。利用位图联结索引，我们能对DEPT.DNAME列建立索引，但这个索引不是指向DEPT表，而是指向EMP表。这是一个全新的概念：能从其他表对某个表的属性建立索引。
以下创建的索引：
system@ORCL>create bitmap index emp_bm_idx 2 on emp( d.dname ) 3 from emp e, dept d 4 where e.deptno = d.deptno 5 /索引已创建。它会在表上创建索引INDEX_NAME。在此引用了DEPT表中的一列：D.DNAME。这里有一个FROM子句，使这个CREATE INDEX语句有些像查询。另外，多个表之间有一个联结条件。这个CREATE INDEX语句对DEPT.DNAME列建立了索引，但这在EMP表的上下文中。数据库根本不会访问DEPT，而且也不需要访问DEPT，因为DNAME列现在是在指向EMP表中的行的索引中。为了便于说明，我们把EMP表和DEPT表制作得看上去很”大“（以避免CBO认为它们很小，以至于选择执行全面扫描，而不是使用索引）：
system@ORCL>begin 2 dbms_stats.set_table_stats( user, 'EMP', 3 numrows => 1000000, numblks => 300000 ); 4 dbms_stats.set_table_stats( user, 'DEPT', 5 numrows => 100000, numblks => 30000 ); 6 end; 7 /PL/SQL 过程已成功完成。然后再执行查询：
system@ORCL>set autotrace traceonly explainsystem@ORCL>select count(*) 2 from emp, dept 3 where emp.deptno = dept.deptno 4 and dept.dname = 'SALES' 5 /执行计划----------------------------------------------------------Plan hash value: 2538954156------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|Time |------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 3 | 1 (0)|00:00:01 || 1 | SORT AGGREGATE | | 1 | 3 | | || 2 | BITMAP CONVERSION COUNT | | 333K| 976K| 1 (0)|00:00:01 ||* 3 | BITMAP INDEX SINGLE VALUE| EMP_BM_IDX | | | | |------------------------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 3 - access("EMP"."SYS_NC00009$"='SALES')system@ORCL>select emp.* 2 from emp, dept 3 where emp.deptno = dept.deptno 4 and dept.dname = 'SALES' 5 /执行计划----------------------------------------------------------Plan hash value: 615168685---------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 6249M| 296G| 133K (34)| 00:26:43 ||* 1 | HASH JOIN | | 6249M| 296G| 133K (34)| 00:26:43 ||* 2 | TABLE ACCESS FULL| DEPT | 25000 | 317K| 8143 (1)| 00:01:38 || 3 | TABLE ACCESS FULL| EMP | 1000K| 36M| 81422 (1)| 00:16:18 |---------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 1 - access("EMP"."DEPTNO"="DEPT"."DEPTNO") 2 - filter("DEPT"."DNAME"='SALES')位图联结索引确实有一个先决条件。联结条件必须联结到另一个表中的主键或惟一键。
