Hash clustered table与索引聚簇表非常相似,只有一个主要区别:聚簇键索引被一个hash函数所取代,表中的数据就是索引.所以没有物理索引

hash clustered table也有副作用,如果不对表加一个传统索引,将无法对表进行range scan,比如 select * from emp where deptno between 10 and 20,会产生全表扫描.

理想情况下，散列值均匀地分布到为散列聚簇分配的所有块上，从查询利用一个I/O就能直接找到数据。实际中，最后可能会有多行数据的散列值散列到同一个数据库块地址，而且这个块上放不下这么多行，这就会导致块串链，用一个链表把块串起来，来保存散列到这个块的所有行，当需要获取与某个散列键匹配的行时，可能必须访问多个块。此外，散列冲突也会增加开销，使块串联的可能性增加。

相关参数：

HASHKEYS：Oracle将HASHKEYS值“舍入”为与之最接近的质数(散列键数总是一个质数)，然后再将SIZE参数乘以修改后的HASHKEYS值，根据这个结果为聚簇分配空间。也就是至少需要分配的空间字节数。可以用公式(HASHKEYS/trunc(blocksize/SIZE))来计算散列聚簇需要预留的最少块数量。对一个几乎为空的散列聚簇进行全表扫描与全面扫描一个满的散列聚簇所花的时间是一样的。所以，建立散列聚簇的目的是为了根据散列键查找从而非常快地访问数据,而不是为了频繁地对它进行全面扫描。

HASH IS：此选项用来指定散列函数。可以指定一个SQL函数。如果不指定则使用Oracle内部的散列函数。

SINGLE TABLE：此选项用来指定创建单表散列聚簇(single table hash cluster)，这是散列聚簇有一个特例。它只支持聚簇中存在一个表。这种散列聚簇是为按主键来快速访问一个表而设计得。单表散列聚簇需要更少的缓冲区latch来完成处理,并CPU的用量会大幅减少

创建散列聚簇表步骤如下：

创建散列聚簇

create cluster emp_dep_cluster (depno number(2)) hashkeys 100 size 2048 hash is depno;

创建表

create table department (

depno number(2) primary key, depname varchar2(20))

cluster emp_dep_cluster(depno);

create table employee (

empno number primary key, empname varchar2(20),

depno number(2) references department(depno))

cluster emp_dep_cluster(depno);

hash clustered table的要点是:

1)hash clustered table中是把传递到查询的需求转换成一个FILE/BLOCK,并且直接读,不经过索引.

2)hash clustered table的I/O要少得多,因为heap table要至少做一次I/O来获取rowid,然后通过rowid来访问表

3)散列聚簇查询与索引查询所用的CPU是一样的,尽管它访问buffer hash的次数要少得多。但执行hash是一个CPU相当密集的操作(索引是I/O密集的操作).这里要做个权衡.

hash clustered table小结

1) 散列聚簇一开始就要分配空间。Oracle根据你的HASHKEYS和SIZE来计算HASHKEYS/trunc

(blocksize/SIZE)，立即分配空间，并完成格式化，一旦将第一个表放入这个聚簇中，任何

全面扫描都会命中每一个已分配的块。在这方面，它与其他的所有表都不同。

2) 散列聚簇中的HASHKEY 数是固定大小的。除非重新聚簇，否则不能改变散列表的大小。这

并不会限制聚簇中能存储的数据量，它只是限制了能为这个聚簇生成的惟一散列键的个数。如

果HASHKEY 值设置得太低，可能因为无意的散列冲突影响性能。

3) 不能在聚簇键上完成区间扫描。诸如WHERE cluster_key BETWEEN 50 AND 60 谓词条件

不能使用散列算法。介于50～60 之间的可能值有无限多个，服务器必须生成所有可能的值，并

分别计算散列，来查看相应位置是否有数据。这是不可能的。如果你在一个聚簇键上使用区间

扫描，而且没有使用传统索引，实际上会全面扫描这个聚簇。

散列聚簇适用于以下情况：

· 很清楚表中会有多少行，或者知道一个合理的上界。HASHKEY和SIZE参数的大小要正确，这对于避免聚簇重建至关重要。

· 主要执行获取操作相比，DML(特别是插入)很少。更新不会引入严重的开销， 除非更新了HASHKEY(更新HASHKEY会导致行迁移)。

· 经常按HASHKEY值访问数据。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29337971/viewspace-1062759/，如需转载，请注明出处，否则将追究法律责任。