Oracle位图索引同标准的b-tree索引可就大不相同了。位图结构是一种二维数组，由被索引的数据表内某一列的各行产生。在位图索引中，每一列就代表一个可起区分作用的值。这种二维数组代表了数据表内列乘以行数的索引中的每个值。在取得各行的时候，Oracle就把位图解压缩并存放在内存缓冲内，这样数据可以很快地被扫描来匹配实际值。这些匹配的值再以Row-ID
列表的形式交付给Oracle，而这些Row-ID值可以直接访问所需要的信息。
位图索引特别适用于表内包含多个位图索引这种情况：每个单列都可能会有较低的基数。创建多个位图索引这种方法就可以更快的速度决绝SQL查询所面临的困难。
再如，假设现在有一个汽车数据库，其中包含了大量的低基数列，比如car_color、car_make、car_model和car_year等。以上这些列各自包含的值数目不超过100，b-tree索引在一个包含2000万辆汽车数据的数据库面前毫无用处。但是，把这些索引组合到一个查询里就会相比传统查询读取表内2000万行记录的速度要快得多。比如，假设我们想找出1981年生产的老式Toyota
Corollas汽车，其查询情况请见清单B。
Oracle采用了专门的优化器把位图索引合并起来服务于查询操作。在位图索引合并的情况下，每一个Row-ID或者说RID列表都采用位图独立创建，一种专门的合并程序则用来比较RID列表同时找出交叉值。采用这种方法，Oracle就可以在处理多个低基数列的同时实现更快的响应时间（请参看图B）。
图B
Oracle位图合并连接
Oracle索引有一个最重要的高明之处，这就是引入了基于函数的索引。基于函数的索引可以根据表达式、内部函数以及用户用PL/SQL和Java编写的函数来创建索引。基于函数的索引保证了Oracle设计人员能采用索引作为其查询手段。在Oracle8之前，内置函数的采用不能满足索引的性能要求。最终，Oracle只能执行严重损害查询性能的全规模扫描。基于函数的SQL示例可能包含以下内容：
Select * from customer where substr(cust_name,1,4) = ‘BURL’;
Select * from customer where to_char(order_date,’MM’) = ’01;
Select * from customer where upper(cust_name) = ‘JONES’;
Select * from customer where initcap(first_name) = ‘Mike’;
在Oracle9i系统下，Oracle总会检查SQL 表达式的where子句查看是否存在匹配的索引。在基于函数的索引这一情况下，Oracle设计人员可以创建用SQL
where语句准确判断的匹配索引。这样就保证了查询可以最低程度的磁盘读写和最快的速度得到结果。
从Oracle8开始，Oracle认识到对每一列采取索引的表并不需要数据表的行。换句话说， Oracle承认，采用专门的数据表访问方法（称做索引快速全扫描）的话，索引就可以在并没有实际接触数据本身的情况下完成数据查询。
Oracle用唯索引表结构（IOT）实现了以上的想法。在使用IOT的情况下，Oracle并不创建实际的表而是把所有需要的信息都保存在Oracle索引之内。在查询的时候，Oracle
SQL优化器在索引树内找出服务于现有查询的所有必要的值，此时，Oracle根据查询代价的优化器选择读取索引树节点然后按序取出数据或者调用索引快速全扫描，后者将用全表扫描同样的方式采用连续预取（由db_file_multiblock_read_count参数定义）方法读取数据表。Multiblock读取工具可以让Oracle很快地线性扫描索引块，快速地读取索引表空间内的每一块。清单C就包括了创建IOT的语法示例。
Oracle在关系型数据库市场上占据这龙头老大的地位，所以Oracle的设计师必须关注特殊的索引结构而且完全理解索引用来提升Oracle SQL查询的方法。这类技术很多都在图书《Oracle High-Performance SQL Tuning》（Oracle公司2001年出版）中进行了讨论。该书对创建所有Oracle索引树结构的过程进行了详细的讨论，同时还提出了一些特殊的技巧和相关技术，借以保证SQL查询能用到最快和最有效率的索引结构。
