Concepts-第5章部分翻译(3)

索引的内部结构
oracle用B-树结构来存储索引来加速数据的访问。如果没有索引，那么要找到一个值就必须对数据块做一个顺序的扫描。对于n行的数据，
采用顺序扫描来说就需要n/2次扫描。当数据量增长时，这种的扫描并不是很好的扫描方法。
考虑一个已经对值排好序的列表按照块的大小分成很多范围。 这些用指针指向数据块的范围的末端点能够被存储在查询B-树上，并且对于
输入n来说按照log(n)的计算出来的值能够被找到。这个是在oracle索引背后的基本原理。

5-7图说明B-树索引的结构：



一个B-树的上部分(分支块)包含了那些指向低1级的索引块的数据。最低级的索引块(叶子块)包含了每个被索引的数据值以及相应的用来
定位实际的记录行的rowid的值。叶子块之间是双向链接起来的。那些被索引的列中有字符数据的索引是基于数据库字符集的字符的二进
制值来编入索引树的。
对于一个具有唯一特性的索引，对于一个数据值只有一个rowid存在。对于一个非唯一性的索引,rowid会按照已经排好的顺序被存放在索
引的键上，所以非唯一性的索引会根据索引的键值和rowid来排序。那些包含null值的键值是不被编入到索引树上的，除非对于集群索引。
对于包含null值的两行可以不用违反唯一性索引的约束而可以存在表中，因为此时的唯一性约束对null无效。

索引属性
索引树中有两种数据块：
*为方便查找的分支块
*以及用来存储值的叶子块

分支块
分支块是用来存储下面的信息：
*用来在两个索引键值之间起决定分支作用的最小的索引键的前缀
*包含索引键并且是指向孩子块的指针
如果这些块有n个索引键，那么这些块就有n+1个指针。索引键和指针的数量被这些块中单个块的大小所决定。

叶子块
所有的叶子块都距离根节点的块的深度是一样的，叶子块存储下面的信息：
*每行的全部索引键值
*表中行记录的rowid

B-树结构的优点
B-树结构有下面的优点：
*索引树上所有的叶子块都有同样的深度，所以在索引树上获取任何一条记录花费的时间大概相等
*B-树索引能够自动的保持平衡
*B-树上的所有的块平均是3/4的空间被利用
*B-树为大范围的查询，包括精确查询以及范围查询提供了一个极好的查询获取数据的性能
*插入，更新以及删除是及时维护索引树上的索引键值，为了快速获取数据的目的
*B-树的性能对于小表和大表都是好的，并且不会随着表的数据量增大而性能降低

唯一索引扫描
唯一索引扫描对于访问数据来说是最有效的方法之一。这种访问方法用来从B索引树中返回数据.当一个唯一性索引的所有列用相等的条件
来定义，优化器会选择唯一索引扫描；

范围索引扫描
范围索引扫描对于访问选择性的数据时是一个比较普遍的操作。它可以是有界限的(两边都有限制)或者是没有界限的(一边没有界限或者
两边都没有界限)。数据是按照被索引列的升序返回。对于是相同的行的返回是按照它们的rowid的升序来排序。

关键字浓缩
关键字浓缩让你在索引或者索引结构的表中压缩主键列上的值的部分，这样做减少重复值的存储费用。
通常，在索引上的键有2块组成，组块和唯一性的块。如果键上没有定义这个键有唯一性的块，oracle将以rowid的形式提供一个键向添加
到组块。键浓缩是一种摆脱组块的方法来存储键以便键能够被若干唯一的块所共享。

前缀和后缀标识
键浓缩将索引键分成前缀条目(组块)和后缀 条目(唯一性的块)。键浓缩是通过在索引块中的所有后缀条目中共享前缀条目来实现的。只有
B树索引的叶子节点中键才被压缩。在分支块中键的后缀被截断了，并且键没有被压缩。
键浓缩是在一个索引块中被处理的但是不会跨越多个索引块。后缀条目构成索引行的压缩版。每个后缀条目引用一个前缀条目，这个被引
用的前缀条目也和这个后缀条目存放在同一个索引块中。
默认的，前缀是由所有的键的列包括最后一个列组成的。例如：在一个有三列（列1，列2，列3）组成的键中默认的前缀是(列1，列2).对
于一个值的列表：(1,2,3),(1,2,4),(1,2,7),(1,3,5),(1,3,4),(1,4,4),在前缀中(1,2),(1,3)重复出现，所以(1,2),(1,3)bei 压缩。
也可以通过定义前缀的长度，也就是在前缀中列的个数。比如：如果你定义一个前缀的长度是1，这样你的前缀就是(列1)，后缀是(列2,
列3)。对于一个列表:(1,2,3),(1,2,4),(1,2,7),(1,3,5),(1,3,4),(1,4,4)，在前缀中重复出现的1被压缩。
对于一个非唯一性的索引来说最大的前缀长度是主键列的长度，并且对于一个唯一性的索引来说最大的前缀的茶馆年度是主键列的个数-1。
如果索引块已经不包含一个前缀条目，但是这个索引块的值等于当前的前缀条目，在这个时候前缀条目被写入索引块中。前缀条目当被写
入索引块中就可以被共享出来是可获取的，并且一直是可以被获取的直到最后一个被删除涉及到的后缀条目被清除出索引块。

性能和存储的考虑
键浓缩可以节省大量的空间，让你在每个索引块中存储更多的键，这样能够减少I/O来提高性能。
尽管键浓缩减少了索引的存储空间的需求，但是在索引扫描的时候键浓缩将需要更多的CPU时间来重构主键列的值。键浓缩也会招致一些
额外的存储费用，因为每个前缀条目都会有一个4个字节的空间费用。

键浓缩的利用
键浓缩在许多不同的场景是非常有用的，比如：
*在一个非唯一性的常规索引中，oracle将用rowid来存储相同的键值到指定的键上来使相同的行分开。如果使用键浓缩，oracle将在索
引块上不需要rowid来存储这个相同的键值作为一个前缀条目。行的其他部分是只有由rowid组成的后缀条目。
*在具有(项目，时间)形式的主键的唯一性索引中会发现有同样的行为，例如(stock_ticker, transaction_time).成千行的数据有同样
的stock_ticker值，并且用transaction_time来保证唯一性。在一个特殊的索引块中一个stock_ticker值作为一个前缀只存储一次，在
索引块的其他条目是 transaction_time 值，这些值是作为后缀条目并且引用一般的stock_ticker的前缀条目来存储的。
*在那些包含数组或者嵌套表类型的索引结构的表中，对象标识符对于集合类型的每个元素是重复的。键浓缩让你压缩这些重复的对象标
识符的值。
在有些情况下，键浓缩是不能被采用的，例如：一个带有单独的属性的键的唯一性索引，键浓缩是不可能的，因为尽管有唯一块存在，但
是没有组块来共享。

反键索引
创建一个反键索引，和一个标准的索引比较，就是使被索引的每一列(除了rowid)上的字节按照反过来存放同时也保持列的顺序。比如一个
排序能够帮助避免在集群应用中的性能降低，并且这个排序只需要对索引的修改部分很小，只集中在一个小的叶子块的集合中。通过将索
引键的反序，插入将在索引树中分布在所有的叶子键中。
采用反键排序消除了在索引树上进行索引范围查询的能力。因为用反键索引形式原来词汇相近的键在存储上并不相临，只有在通过键值查
询以及全索引(表)扫描能够被执行；
有时候，用反键索引可以使一个OLTP集群应用应用地更快。例如：在一个邮件应用中保持邮件信息的索引：一些用户保留了老的信息，并
且索引必须维护那些指向老的邮件信息的指针 ，也要维护指向最近的邮件信息的指针；
REVERSE关键字提供了一个简单的创建一个反键索引的机制。你可以在create index语句中定义一个带有REVERSE关键字的随意的索引：
CREATE INDEX i ON t (a,b,c) REVERSE;
你可以定义一个带有NOREVERSE关键字来重建反键索引使得键不是反向键入的：
ALTER INDEX i REBUILD NOREVERSE;
重建一个反键索引没有带有NOREVERSE关键字产生一个重建的，反键的索引。

位图索引
一个索引的目的是提供一个指向在表中行的指针，这个指针也包含被给予的键值。在常规的索引中，索引的目的的实现是通过存储对应键
值的相应行的rowids的一系列rowids的列表。oralce用每一个被存储的rowid来重复存储每一个键值。在位图索引中，一个位图对应一个键
值的方法来代替一系列的rowid的列表。
在位图中的每一位对应一个可能的rowid.如果位图的一位被设置一个rowid，就意味着这个rowid对应的行包含一个键值。一个映射函数将
位图中的位转换为实际的rowid，所以位图索引提供象常规索引一样的功能，尽管它在内部用的是不同的表示法。如果不同的索引键值的个
数很小，则位图索引的空间效率是很好的。

高效定位的位图合并那些对应WHERE条件中几个条件的索引。满足条件中的一些，但不是所有条件的行在表自身被访问之前被过滤出去。这
个动态地改进了响应时间。

数据仓库应用的好处
位图索引对那些有大量数据并且有特别的查询但是低并发事务的数据仓库是有好处的。对于这样的应用，位图索引提供：
*对于大量特别的查询类，可以减少查询的响应时间；
*相对于其他索引技术位图索引减少了对空间的需求；
*甚至在非常低端的硬件上获得很好的性能；
*非常有效的并发DML操作以及并发的工作量；

用传统的B树索引来对一张大的表索引会在空间方面消耗昂贵，因为这个索引可能会是这张表的几倍大。位图索引只需要这张表被索引数
据的大小的一部分的空间比例。

位图索引不适合用于带有大量并发修改数据的事务的OLTP应用程序。这些位图索引主要用在用户只需要查询数据而不需要更新数据的用于
做决策支持的数据仓库中。

位图索引不适合于那些主要带有大于或者小于比较的查询上的列上。比如：一个经常出现在where条件中以和一定值做比较的工资字段则
采用B树索引更好。位图映射的索引在带有等号的查询，特别是和and，or或者not操作符结合的情况下是有用的。

位图索引是和oracle优化器以及执行引集成在一起的。他们可以无障碍的和其他oracle执行方法一起使用。比如：优化器可以决定对两张
表进行hash连表，并且在一张表上采用位图索引，在另一张表上用常规的B树索引。优化器考虑位图索引和其他的有用的访问方法，比如
常规的B树索引和全表扫描，并且在适当的时候将并发操作也考虑进去从而选择最有效的方法。

用位图索引进行并行查询以及并发DML操作和常规的索引一样。在分区表上的位图索引必须是本区的索引。并发的创建索引记忆索引之间
连接也是支持的。

基数
对于技术比较低的列用位图索引是优势最大的，基数低是指和表中的记录的数量相比这列上的不同的值的个数是很少的。如果一列上的不
同值的个数占表中的记录数的比例是小于1%的，或者在列上的值重复出现了100次，然后这列是位图索引的后选者。如果在where条件中那
些带有低重复数即高基数的列趋向于被包含于复杂条件的查询中也可以作为后选者。

比如：一张有100万条记录的表，一个有1万种不同的值的列可以作为位图索引的后选者。在这列上建位图索引可以比建B树索引要好，特别
是当这列经常是和其他列联合一起被查询的时候。

B树索引对于高基数的数据是很有效的：也就是有许多可能的值的数据，比如CUSTOMER_NAME或者PHONE_NUMBER。在一些环境下，B树索引树
会比被索引的数据还要大。适当的应用位图索引所消耗的空间比相应的B树索引要小的多。

在特别的查询以及同样的环境，位图索引可以很显著的改进查询性能。在where查询条件中and或者or条件判断在将位图结果转化为rowids
之前通过在位图上直接执行相应的布尔操作可以快速的解决。如果返回的行数很小的话，查询可以不需要对表进行全表扫描来重新排序而
能够非常快的查询出结果。

位图索引例子
表5-1 显示了公司客户数据的一部分
CUSTOMER # MARITAL_ STATUS REGION GENDER INCOME_ LEVEL
101 single east male bracket_1
102 married central female bracket_4
103 married west female bracket_2
104 divorced west male bracket_4
105 single central female bracket_2
106 married central female bracket_3

MARITAL_STATUS,REGION,GENDER和INCOME_ LEVEL都是低基数的列。对于结婚状态以及地区只有3个可能的值，对于性别只有2个可能的值，
对于收入水平只有4个种值。因此，在这些列上创建位图索引是很适合的。位图索引不应该在CUSTOMER#列上创建因为这列是一个高基数的
列。取而代之的是这列上用唯一性的B树索引来提供最高效的表示法和获取方式。

表5-2说明在这个例子中为地区创建的位图索引。它是由3个单独的位图组成，每个地区设置一个位图。
REGION='east' REGION='central' REGION='west'
1 0 0
0 1 0
0 0 1
0 0 1
0 1 0
0 1 0
在位图上的每一位对应于CUSTOMER表的一个单独的行。每一位的值依赖于在表中相应行的值。例如：上面的图中位图REGION='east'包含一
行数据作为位图的第一位。这是因为地区为东的是CUSTOMER表的第一条记录。位图REGION='east'为其他的位写0是因为表的其他行在他们
的REGION字段上没有包含为东的记录。
人口统计研究学家想知道公司客户的分布情况，就问：在中部和西部有多少已经结婚的客户？这个可以用下面的语句来实现：
SELECT COUNT(*) FROM CUSTOMER
WHERE MARITAL_STATUS = 'married' AND REGION IN ('central','west');
通过用位图索引计算在位图结果中是1的个数来高效地处理这个查询，象图5-8所说明的。为了识别满足要求的指定的客户，结果位图能够用来访问表。



位图索引和Nulls
位图索引可以包含那些有null值的行，不像大多数其他类型的索引。Null值被索引对于一些SQL语句类型是有用的，比如带有聚合函数计算总数的查询。

分区表上的位图索引
像其他索引一样，你可以在分区表上创建位图索引。仅有的限制是位图索引必须是被分区的表的局部索引—它们不能是全局索引。全局位图索引只在非分区的表上支持。

位图连表索引
除了在单个表上创建位图索引，你可以创建位图连表索引，位图连表索引是指为2张表或者多张表的连表所创建的位图索引。减少在必须要根据预先的限制来连表出来的数据量方面，一个位图连表索引是节省空间的有效方法。对于表中列的每一个值，位图连表索引存储了在一张或者多张其他表行的rowids。在数据仓库环境中，连表的连接条件是在维表的主键列和真实表的外键列之间的等价内连接。
位图连表索引在存储上比基于连表的物化视图节省空间更加有效，和基于连表的物化视图比较会选择位图连表索引，这是因为基于连表的物化视图不会浓缩真实表的rowids.

索引组织表的概述
索引组织表有个一个存储组织，这个存储组织结构是最初的B树结构的一个变种。不像一般的表（堆组织表），堆组织的表的数据被作为一个无序的数据集合（堆）来存储的，但是索引组织表的数据是按照主键排好序之后存储在B树索引结构上的。不仅存储了索引组织表中每行的主键列上的值，而且在B树上的每个索引入口也存储了也存储了非主键列上的值。
在图5-9中，索引组织表有点类似于一个由一般的表和一个定义在一列或者多列上的索引组成的结构，但是数据库系统只维护一个单独的B树索引，而不是同时维护两个单独的存储结构—一个表结构以及一个B树索引结构。并且不仅将行的rowid存储在索引的入口，非主键的值也被存储在里面，索引每个B树索引入口包含<主键列上的值，非主键列上的值>。
图5-9：常规表和索引组织表的比较



应用软件使用索引组织表就和一般的表一样，用SQL语句。但是，数据库系统执行所有的操作只需要通过操作相应的B树索引即可。
表5-3总结了索引组织表和一般表的不同点。
表5-3索引组织表和一般表的比较

一般表	索引组织表
Rowid能够唯一的确定一数据行。主键是选择地被指定的。	主键唯一的确定一数据行。主键必须被指定。
在rowid的虚拟列中物理的rowid允许建二级索引。	在rowid的虚拟列中的逻辑rowid允许建二级索引
通过rowid来访问数据	通过逻辑rowid来访问数据
顺序扫描并且返回所有的行	全索引扫描返回所有的行
可以和其他的表一起被存储在簇表中	不能被存储在簇表中
可以包含long类型和lob类型的列	可以包含lob类型的列但是不可以包含long类型的列

索引组织表的优势
索引组织表可以通过主键或者任何一个有效的带有主键前缀的键来提供对表记录的快速访问。在索引组织表在中B树的叶子块自身存储了每行非主键的列的值，这样就避免了一个额外的数据块的访问。也因为行是按照主键排好序的顺序存储的，所以通过主键或者以主键为前缀的键来进行的范围访问所访问包含的数据块是最少的。
为了能够更快的访问被频繁访问的列，可以采用一个行溢出段（之后会描述）将那些不经常被访问的非主键的列从B树的叶子块中挤出去存放到一个可选的（堆组织）的溢出段中。这样的方法限制了实际存储在N树叶子块中的每行的大小和内容，从而在每个叶子节点上可以存储更多的行记录并且B树也会变小。
带有主键索引的堆组织表中主键列不仅被存储在表中也存储在索引中，但是在索引组织表中不像堆组织表的结构来重复存储主键，因为主键列的值只存储B树索引中。
因为行是按照主键的顺序来存储的，额外的存储空间储蓄的一个重要数量是可以通过键浓缩的方式获取。
基于逻辑rowid的主键的利用，和物理rowid相反，在索引组织表中的二级索引允许高可用性。这是因为，归咎于rowid的逻辑本质，即使一个表的重新组织蚕做使得基表行的移动，二级索引也不会变为不可用状态。同时，在逻辑rowid中通过物理的猜测，基于索引组织表访问来获取二级索引是可能的，并且访问的性能与基于对一般表的访问获取二级索引的性能是可比的。

带有行溢出域的索引组织表
B树索引入口通常是非常的小，因为它们只由键值和rowid组成。在索引组织表中，相反的，B树索引入口是可以很大的，因为它们是由整个行组成。这样有可能会破坏B树密集的聚类属性。
Oracle提供

OVERFLOW

语句来处理这个问题。可以定义一个溢出表空间，以便在需要的时候，一行记录可以被分成下面的两部分，分别存储在索引中和溢出存储段中：
*索引入口：包含所有主键列的列值，一个指向行溢出部分的物理rowid以及一些选择性的非键列上的列值
*溢出段：包含剩下的非键列上的列值

采用

OVERFLOW

，可以通过

PCTTHRESHOLD

和

INCLUDING

语句来控制oralce是如何决定是否一行需要两部分来存储，并且当采用两部分来存储时在哪个非键列上将一行断开两部分的。通过用

PCTTHRESHOLD

语句，可以定义一个数据块大小的极限值。如果所有的非键列值能够在指定的极限值之内被容纳下，则该行将不会被破坏分成两部分。相反的话，则从第一个不能被容纳下的非键列开始，这张表的剩下的非键列都被存储在行溢出段中。

INCLUDING

语句让你指定列名以便在

CREATE

TABLE

语句中任何出现在那个被指定列之后的非键列被存储在行溢出段中。注意额外的非键列可能有时候由于

PCTTHRESHOLD

的限制也被存储在溢出段中。

索引组织表的二级索引
支持索引组织表的二级索引利用那些既不是主键也不是以主键为前缀的键的列来提供对索引组织表的的高效的访问。
Oracle利用索引组织表的主键的逻辑行标识（逻辑rowid）来构造二级索引。一个逻辑rowid包含了物理猜测，这个物理猜测标识了行记录在数据块中的位置。Oracle能够利用这些物理猜测来直接探查到索引组织表中叶子块里面，绕过了用主键查找。因为在索引组织表中没有永恒的物理地址，当行记录被移动到新的数据块时物理猜测变的相对稳定。

对于一般的表来说，通过二级索引来访问数据包含一个二级索引的扫描以及一个额外的为获取包含该行数据块的磁盘I/O。而对于索引组织表来说，通过二级索引访问数据会变，主要依赖于物理猜测的利用和物理猜测的正确性。
*没有物理猜测，访问数据包含两个索引扫描：主键索引扫描以及紧跟之后的二级索引扫描。
*利用精确的物理猜测，访问数据包含一个二级索引的扫描以及一个额外的为获取包含该行数据块的磁盘I/O。
*利用不精确的物理猜测，访问数据包含一个主键索引饿扫描，还有紧跟其后的一个二级索引的扫描以及一个额外的为获取包含该行数据块的磁盘I/O。

索引组织表上的位图索引
Oralce支持在分区的索引组织表和非分区的索引组织表上创建位图索引。在索引组织表上创建位图索引需要一个映射表。
映射表
映射表是一个用来存储索引组织表的逻辑rowids的一个堆组织表。特别地，映射表中的每行存储了在索引组织表中相应行的逻辑rowid。因此，映射表提供了在索引组织表中行的逻辑rowids和在映射表中行的物理rowids一个一对一的对应关系。
在索引组织表中的位图索引除了那些在索引组织表上的位图索引的rowids是映射表的rowids而不是基表的rowids这点不同之外，其他的类似于堆组织表。对于每个索引组织表只有一个映射表并且所有创建在索引组织表上的位图索引都会用这张映射表。
在堆组织表以及索引组织表的基表中，位图索引通过搜寻键而被访问。如果键被找到，位图入口被转化为物理的rowid。在堆组织表中，物理的rowid然后被用来访问基表。但是，对于索引组织表，物理的rowid被用来访问映射表。对映射表的访问产生一个逻辑rowid。这个逻辑rowid被用来访问索引组织表。
尽管索引组织表上的位图索引不存储逻辑rowid，但是本质上该位图索引存储的rowid还是逻辑的rowid 。

分区的索引组织表
可以通过索引组织表上的列值来对索引组织表进行

RANGE

,

HASH

, 或者

LIST

分区。分区的列必须组成一个主键列的子集。和一般的表一样，局部分区的前缀和非前缀索引以及全局前缀索引对于分区的索引组织表来说都是支持的。

对于堆组织表和索引组织表上的UROWID类型的列的B树索引
UROWID类型的列可以容纳基于键的逻辑rowids来识别索引组织表的行。Oralce支持在堆组织表的UROWID类型列上的索引。这种所支持在ROWID类型列上的相等谓词。对于不是相等的谓词或者对于基于UROWID类型列的排序，这个索引是不支持的。

索引组织表的应用
对于基于主键查询的很好的查询性能，高可用性，以及减少存储空间的需求方面在下面的应用情况下用索引组织表是理想的：
*在线事务处理；
*网络（例如：查询引擎以及入口）；
*电子商务（例如：电子存储和分类）
*数据仓库；
*分析函数；

应用域索引的概述
Oracle提供一个可扩展的索引定义来满足自定义的复杂类型上的索引，比如：文档，空间数据，图片以及视频处理等等，自定义索引充分利用了专业的定义索引的技术。用可扩展索引，你可以将应用于特定领域的索引的管理程序压缩成为一个indextype对象，然后在一个对象类型的属性上或者表的列上定义一个域索引。可扩展索引也提供了对特定应用的操作的有效处理。
应用软件，也被叫作弹药筒，控制一个域索引的结构和内容。Oracle数据库服务器与应用软件相互作用来构建，维护以及查询域索引。索引结构本身可以作为一个索引组织表或者作为一个外部文件被存储在数据库中。

簇的概述
簇是用来存储表数据的一种可以选择的方法。一个簇是由共享同样数据块的一组表组成，因为它们有相同的列并且经常一起被用。例如：employees和department表都有department_id列。当将employees和department表簇合在一起，oracle在物理存储上将employees和department表里面的具有相同部分的所有的行存放在相同的数据块中。
图5-10显示了当将employees和department表簇合在一起内部存储上发生了什么？
图5-10：



因为簇将不同的表中的相关的行记录都存储在相同的数据块中，适当地采用簇可以提供下面的好处：
*簇里面的表之间的连接减少了磁盘I/O的读取；
*簇里面的表之间的连接提高了访问时间；
*在簇中，对于一个特定的行簇键值是簇键列上的值。在存和簇索引中，每个簇键值仅被存储一次，不管在不同的表内部对应该键值有多少行对应的记录。因此与非簇表的形式相比，簇表需要用来存储相关的表以及索引数据的存储空间要少。比如：在5-10图中，注意在employees和department表包含的相同的簇键值（每个department_id）尽管有很多对应的行记录，但是簇键值仅存储一次。

哈希簇的概述
哈希簇以类似于常规索引簇（以索引的键来簇合而不是用哈希函数来簇合）的方式来给表数据分组。一行记录是根据对该行的簇键值应用哈希函数的结果被存储在哈希簇中。具有相同的键值的所有行在磁盘上被存储在一起。

当一张表被频繁地用等号查询（比如：返回所有department为10的记录），此时采用哈希簇比用一个索引表或者索引簇要好。对于带有相等的这类查询，指定的哈希键被推敲。键值被推敲之后的结果直接指向在磁盘上存储这些查找出来的记录的区域。

散列法是改进数据获取性能的一种存储表数据的方法。为了利用散列法，创建一个哈希簇并且将表加载到簇中。Oracle物理上以哈希簇来存储表的记录并且根据哈希函数的结果来读取数据。
被排序的簇对应用软件来说允许更加快速的获取数据，因为在簇中数据是按照数据被插入的顺序被消耗的。

Oracle用一个哈希函数来产生对数字值的分配，叫哈希值，哈希值是基于指定的哈希键值产生的。哈希簇的键，与索引簇的键相似，可以是单独的列或者是复合的键（多列键）。为了在哈希簇中找到一行或者存储一行，oracle对该行的簇键值应用哈希函数。产生的哈希值对应于簇中的一个数据块，然后oracle代表被发布的语句来读取或者写进这些哈希值。

哈希簇与一个带有索引或者索引簇的非簇表来说是个可供选择的放法。在饿比索引的表或者索引簇中，oracle用存储在单独的索引中的键值来定位表中的行记录。为了找到存储在被索引表或者簇中的一条行记录，至少两个I/O需要被执行：
*在索引中为找到或者存储键值需要一次或多次的I/O交互；
*向表中或者簇中读取或者写进行记录需要另外一次的I/O交互；