位图索引(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提交。