oracle索引类型和使用技巧

1.不同类型索引和适用范围

Oracle提供了大量索引选项。知道在给定条件下使用哪个选项对于一个应用程序的性能来

说非常重要。一个错误的选择可能会引发死锁，并导致数据库性能急剧下降或进程终止。

而如果做出正确的选择，则可以合理使用资源，使那些已经运行了几个小时甚至几天的进

程在几分钟得以完成，这样会使您立刻成为一位英雄。下面就将简单的讨论每个索引选项。

1.1.B树索引 (默认类型)

树索引在Oracle中是一个通用索引。在创建索引时它就是默认的索引类型。B树索引可以是一个列的(简单)索引，也可以是组合/复合(多个列)的索引。B树索引最多可以包括32列。在下图的例子中，B树索引位于雇员表的last_name列上。这个索引的二元高度为3；接

下来，Oracle会穿过两个树枝块(branch block)，到达包含有ROWID的树叶块。在每个树枝块中，树枝行包含链中下一个块的ID号。

树叶块包含了索引值、ROWID，以及指向前一个和后一个树叶块的指针。Oracle可以从两个方向遍历这个二叉树。B树索引保存了在索引列上有值的每个数据行的ROWID值。Oracle不会对索引列上包含NULL值的行进行索引。如果索引是多个列的组合索引，而其

中列上包含NULL值，这一行就会处于包含NULL值的索引列中，且将被处理为空(视为NULL)。

技巧：索引列的值都存储在索引中。因此，可以建立一个组合(复合)索引，这些索引可以

直接满足查询，而不用访问表。这就不用从表中检索数据，从而减少了I/O量。

B-tree 特点：

适合与大量的增、删、改（OLTP）

不能用包含OR操作符的查询；

适合高基数的列（唯一值多）

典型的树状结构；

每个结点都是数据块；

大多都是物理上一层、两层或三层不定，逻辑上三层；

叶子块数据是排序的，从左向右递增；

在分支块和根块中放的是索引的范围；

1.2．位图索引

位图索引非常适合于决策支持系统(Decision Support System，DSS)和数据仓库，它们不应该用于通过事务处理应用程序访问的表。它们可以使用较少到中等基数(不同值的数量)的列访问非常大的表。尽管位图索引最多可达30个列，但通常它们都只用于少量的列。

例如，您的表可能包含一个称为Sex的列，它有两个可能值：男和女。这个基数只为2，如果用户频繁地根据Sex列的值查询该表，这就是位图索引的基列。当一个表内包含了多个位图索引时，您可以体会到位图索引的真正威力。如果有多个可用的位图索引，Oracle 就可以合并从每个位图索引得到的结果集，快速删除不必要的数据。

Bitmapt 特点：

适合与决策支持系统；

做UPDATE代价非常高；

非常适合OR操作符的查询；

基数比较少的时候才能建位图索引；

技巧：对于有较低基数的列需要使用位图索引。性别列就是这样一个例子，它有两个可能值：男或女(基数仅为2)。位图对于低基数(少量的不同值)列来说非常快，这是因为索引的尺寸相对于B树索引来说小了很多。因为这些索引是低基数的B树索引，所以非常小，因此您可以经常检索表中超过半数的行，并且仍使用位图索引。

当大多数条目不会向位图添加新的值时，位图索引在批处理(单用户)操作中加载表(插入操作)方面通常要比B树做得好。当多个会话同时向表中插入行时不应该使用位图索引，在大多数事务处理应用程序中都会发生这种情况。

位图索引的使用限制：

基于规则的优化器不会考虑位图索引。

当执行ALTER TABLE语句并修改包含有位图索引的列时，会使位图索引失效。

位图索引不包含任何列数据，并且不能用于任何类型的完整性检查。

位图索引不能被声明为唯一索引。

位图索引的最大长度为30。

1.3.HASH索引

使用HASH索引必须要使用HASH集群。建立一个集群或HASH集群的同时，也就定义了一个集群键。这个键告诉Oracle如何在集群上存储表。在存储数据时，所有与这个集群键相关的行都被存储在一个数据库块上。如果数据都存储在同一个数据库块上，并且将HASH索引作为WHERE子句中的确切匹配，Oracle就可以通过执行一个HASH函数和I/O 来访问数据——而通过使用一个二元高度为4的B树索引来访问数据，则需要在检索数据时使用4个I/O。如下图所示，其中的查询是一个等价查询，用于匹配HASH列和确切的

值。Oracle可以快速使用该值，基于HASH函数确定行的物理存储位置。

HASH索引可能是访问数据库中数据的最快方法，但它也有自身的缺点。集群键上不同值

的数目必须在创建HASH集群之前就要知道。需要在创建HASH集群的时候指定这个值。

低估了集群键的不同值的数字可能会造成集群的冲突(两个集群的键值拥有相同的HASH 值)。这种冲突是非常消耗资源的。冲突会造成用来存储额外行的缓冲溢出，然后造成额外的I/O。如果不同HASH值的数目已经被低估，您就必须在重建这个集群之后改变这个值。ALTER CLUSTER命令不能改变HASH键的数目。HASH集群还可能浪费空间。如果无法确定需要多少空间来维护某个集群键上的所有行，就可能造成空间的浪费。如果不能为集群

的未来增长分配好附加的空间，HASH集群可能就不是最好的选择。如果应用程序经常在

集群表上进行全表扫描，HASH集群可能也不是最好的选择。由于需要为未来的增长分配

好集群的剩余空间量，全表扫描可能非常消耗资源。

在实现HASH集群之前一定要小心。您需要全面地观察应用程序，保证在实现这个选项之

前已经了解关于表和数据的大量信息。通常，HASH对于一些包含有序值的静态数据非常

有效。

技巧：HASH索引在有限制条件(需要指定一个确定的值而不是一个值范围)的情况下非常有用。

1.4. 索引组织表

索引组织表会把表的存储结构改成B树结构，以表的主键进行排序。这种特殊的表和其他类型的表一样，可以在表上执行所有的DML和DDL语句。由于表的特殊结构，ROWID并没有被关联到表的行上。

对于一些涉及精确匹配和范围搜索的语句，索引组织表提供了一种基于键的快速数据访问

机制。基于主键值的UPDATE和DELETE语句的性能也同样得以提高，这是因为行在物理

上有序。由于键列的值在表和索引中都没有重复，存储所需要的空间也随之减少。

如果不会频繁地根据主键列查询数据，则需要在索引组织表中的其他列上创建二级索引。

不会频繁根据主键查询表的应用程序不会了解到使用索引组织表的全部优点。对于总是通

过对主键的精确匹配或范围扫描进行访问的表，就需要考虑使用索引组织表。

技巧：可以在索引组织表上建立二级索引。

1.5.反转键索引

当载入一些有序数据时，索引肯定会碰到与I/O相关的一些瓶颈。在数据载入期间，某部

分索引和磁盘肯定会比其他部分使用频繁得多。为了解决这个问题，可以把索引表空间存

放在能够把文件物理分割在多个磁盘上的磁盘体系结构上。

为了解决这个问题，Oracle还提供了一种反转键索引的方法。如果数据以反转键索引存储，