正如我们知道的，Oracle提供了大量索引结构，每种索引结构都有其好处和不足：

* B树索引。从最早的Oracle发行版本开始，Oracle就一直使用的标准树索引就是B树索引。
* 位图索引。当某个索引列含有很少数量的不同的值（即低基数）时，使用位图索引。这对于那些只读数据库而言速度超快，但对需要经常性更新的系统不适合。
* 位图连接索引。这是针对来自其他表的数据列出现在某个连接表的多列索引时使用的索引。下面是在from子句和where子句中使用类似SQL的创建索引的惟一语法。

create bitmap index
   part_suppliers_state
on
   inventory( parts.part_type, supplier.state )
from
   inventory i,
   parts     p,
   supplier  s
where
   i.part_id=p.part_id
and
   i.supplier_id=p.supplier_id;

    尽管有关索引重建的争论仍在激烈进行着，但还是存在每个人都认可的索引管理的某些领域。在内部机制上，一个Oracle B-树索引的结构和一个UNIX I-结点的结构非常相似。索引中的每个数据块都是索引树中的一个结点，位于最底部的结点（叶数据块）包含一对符号键和行ID值。

Oracle b-树索引

    为了正确管理这些数据块，Oracle控制着每个数据块中指针的分配。随着一棵Oracle树的增长（通过往表里插入新行），Oracle会填充这个数据块，当这个数据块满时Oracle会分裂它，创建新的索引结点（数据块）来管理索引内的符号键。

因此，一个Oracle索引块可能包含以下两种类型的指针：

* 指向其他索引结点（数据块）的指针
* 指向数据库表中特定行的行ID指针

    Oracle管理着索引块内指针的分配，这就是为什么我们不能为索引指定一个PCTUSED值（自由列表重链接门槛）的原因。当我们检查一个索引块的结构时，我们发现每个索引结点内部条目的数量是下面两个值的一个函数：

1． 符号键的长度
2． 索引表空间的块尺寸

    由于块尺寸影响每个索引结点内部的符号键的数量，可以推理出：块尺寸对一棵索引树的结构也会有影响。在其他条件相同的情况下，采用32K的大数据块能容纳更多的符号键，从而能够比在2K表空间中创建的相同的索引更加平整。采用大的数据块也将减少索引访问期间一致获取的数量，从而提高分散读访问的性能。

    索引中的每个数据块包含索引树中的“结点”，位于最底部的结点（叶数据块）包含一对符号键和行ID值。随着一棵Oracle树的增长（通过往表里插入新行），Oracle会填充这个数据块，当这个数据块满时Oracle会分裂它，创建新的索引结点（数据块）来管理索引内的符号键。因此，一个Oracle索引块可能包含指向其他索引结点或行ID/符号键对的指针。

索引行为和Oracle块尺寸

    由于块尺寸影响每个索引结点内部的符号键的数量，可以推理出：块尺寸对一棵索引树的结构也会有影响。在其他条件相同的情况下，采用32K的大数据块能容纳更多的符号键，从而能够比在2K表空间中创建的相同的索引更加平整。

    今天，大多数Oracle性能调优专家都利用Oracle提供的多种块尺寸的特色，因为它提供了缓冲区隔离和以最合适块尺寸来存放对象从而减少缓冲区浪费的能力。一些Oracle基准测试的世界记录都使用很大的数据缓冲区和多种块尺寸。

    根据《Oracle数据库管理员认证：“Oracle 认证数据库管理专家”教师指南》一书的作者Christopher Foot的一篇文章，更大的块尺寸在某些情况下非常有帮助：

    “更大的块尺寸意味着在B-树索引的分支结点中有更多的空间来存储符号键，从而可以降低树的高度和提高索引查询的性能。”

    在任何情况下，似乎有证据表明块尺寸影响树的结构，这为数据块影响树的结构提供了有力支持。

    你可以使用大数据块（16-32）缓冲区来存储来自作为重复性大规模扫描对象的索引或表中的数据。这真的会提高性能么？一个小的但透漏内情的测试能回答这个问题。

    在这个测试中，将对某个使用8K数据块尺寸的Oracle 9i数据库执行以下查询，这个数据库同时也使用16K缓冲区和16K大小的表空间。

select
   count(*)
from 
   eradmin.admission
where
   patient_id between 1 and 40000;

表eradmin.admission含有150,000行数据，并在patient_id列上建立了一个索引。对上面的查询语句执行EXPLAIN命令揭示出：它使用索引范围扫描来产生想要的目的结果：

Execution Plan
----------------------------------------------------------
SELECT STATEMENT Optimizer=CHOOSE
(Cost=41 Card=1 Bytes=4)
   1    0   SORT (AGGREGATE)
   2    1     INDEX (FAST FULL SCAN) OF 'ADMISSION_PATIENT_ID'
              (NON-UNIQUE) (Cost=41 Card=120002 Bytes=480008)

    使用位于一个标准8K表空间的索引来执行这个查询（两次以消除分析活动并缓冲任何数据）产生了以下实时统计信息：

Statistics
---------------------------------------------------
          0  recursive calls
          0  db block gets
        421  consistent gets
          0  physical reads
          0  redo size
        371  bytes sent via SQL*Net to client
        430  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed