Btree是平衡查找树，是由一个root节点，若干branch节点，若干leaf节点组成。查找时，会从root节点开始，查找到对应的branch节点，再根据branch节点中记录的值分布，查找到对应的root节点。root节点层是有序的，在这一层还有一个有序双向链表结构，将所有root节点按照key的顺序连接起来，这个双向链表可以大大提高范围查询的效率，比如>, >=, <=, < , between and 等。但是btree对于unique查找和unique in list查找的效率却不是很好。因为对每个unique值的查找都必须经历root -> branch -> leaf 这样的查找，所以每次查找都要访问都是索引的层次数那么多的block。Unique in list类似，有多少个in list 元素，就要访问索引层次的多少倍的block。对于记录数上亿的表来说，索引层次数一般是大于4的。

而hash结构，比如hash cluster，所有的值是按照hash算法来分布的，在进行查找的时候，只需要对key进行相同的hash运算，即可以找到该值对应的地址。所以hash查找的过程是不会产生额外的block访问代价的。然而有的必有失，用hash cluster的代价在于相同的hash值的rows都会保存在预先分配好大小的cluster里，无论这些rows的大小差异如何。

而非hash的普通cluster，可以把它看成是一种特殊的hash cluster，就是每个key都是一个唯一的值，且本身没有经过hash运算，所以无法进行高效的hash 查找。还是要在上面建其他的btree索引。

在hash cluster中，数据和key是放在一起的，与此类似的还有IOT，即索引组织表。索引组织表相对于普通的堆表，优势在于数据即索引，索引即数据，数据是放在索引leaf 节点里的，而堆表上的索引leaf节点只保存rowid。对每个key的访问，可以减少一个对data block的读取。特别对于非unique索引的等值查询，IOT表的优化效果十分明显。

Hash index，oracle没有提供这样的支持，我认为的hash index，数据还是保存在普通的堆表中，而索引占用额外的存储空间，只是索引中按照hash计算地址来保存key和rowid。这样的好处在于，每次对key的查找都只需要访问一次block（当然如果一个key对应大量rowid的时候，这个block的个数会比较多）。对于unique的查找，hash index会比btree index减少不少块读取。

Hash join其实是基于一致读临时建立了一个hash cluster。连接的时候取size较小的一个集合来构建hash cluster，然后另一个集合中的每个元素用hash算法在这个hash  cluster中进行查找，以此来实现等值连接操作。Hash group by也类似，只是操作的集合缩减了一个，当hash cluster构建完成，group操作也已经完成。