Hash分区是通过对分区键运用Hash算法从而决定数据的分区归属。使用Hash分区有什么优点呢？
常用的分区表所具有的优点：如提高数据可用行，减少管理负担，改善语句性能等优点，hash分区同样拥有。此外，由于Hash分区表是按分区键的hash计算结果来决定其分区的，而特定的分区键其hash值是固定的，也就是说Hash分区表的数据是按分区键值来聚集的，同样的分区键肯定在同一分区。
比如，在证券行业，我们经常查询某一只股票的K线，
假设表的结构如下：
Equity表可能会很大，对equity表的查询通常都是指定id,查询某一交易日期或者某段时期内的其他信息。这种情况下我们需要如何为equity表选择分区呢？
单从表本身结构来看，似乎trade_date列很适合被选择用来作范围分区。但如果我们这样分区的话，前面需求中的查询：指定某一id,查询其某一范围内的交易信息，比如看1年内的K线，则这种查询常常需要跨分区。我们知道，对分区表作跨分区查询，很多时候其性能并不会太好，特别是这种查询很可能还要跨很多分区。
你也可能会说，我们再在id, trade_date列上建个索引不就行了，仔细想想是不是这样呢？这时候的equity表中的数据是按trade_date值来聚集的，同样trade_date值的数据常常在一个数据块中，这样前面需求中所描述的查询即使通过索引访问，最终读表时也常常是去读离散的数据块，即每一条记录需要对应读一个表数据块。
如果建成Hash分区表，则数据按hash分区键聚集，就更适合需求中描述的查询，因为同样id的记录必定在同一分区，同时，同样 id值的记录落在同一数据块的几率也增大了，从而“一定程度上”减少了IO。
上面对hash分区减少IO的描述加了引号，因为仅依靠Hash分区表试图实现大范围减少IO操作是不现实的，特别是当equity表中记录的股票数非常多时，同一股票发生在不同交易日的记录在物理上也很难聚集到相同数据块中。实际上，如果我们在Hash分区的基础上再对equity表采用IOT表的组织方式，则前面描述的查询性能就可大为提高。IOT表不在该文讨论的范围之内，这里就不作进一步讨论了。
当我们决定使用Hash表之前，我们还需要确定我们的所选择的分区键值是连续分布的，或者接近连续分区，此外，分区的个数需要是2的整数幂，比如2,4,8… 这些要求是由Hash函数的特点决定的，这样我们分区表的各个分区所包含的数据量才会比较平均。
Hash分区表的扩展：
Hash分区表是通过add partition命令来增加分区的。Oracle推荐分区的个数是2的幂，比如,2,4,8..等等，这样可以确保数据在各个分区中分布比较均匀。当然，如前所述，还需要分区键值是连续分布的，或接近连续分布。
增加新分区时，需要将一些原有的数据从旧的分区划分到新的分区中，那么这种数据划分时来源分区选择遵循什么原则呢？
要点如下：如果要增加的分区是第N个分区，大于等于N的最小2的整数幂为M，则当增加第N个分区时，这个分区的数据来源于分区N-M/2。
比如，现在有个Hash分区表共有100个分区，我们想为其增加一个分区，则它是101个分区，即上面公式中的N为101，而大于101的最小2的整数幂为128，则M为128，于是，这个101分区的数据来源就应该是101-128/2=37分区。
换个角度来说，当我们在增加第101分区的时候，是需要锁定37分区的，因为我们需要将该分区中的部分数据插入到新的101分区中。
下面，我们用一个实例来验证上面的说法，同时看看在实际操作中有什么需要注意的事项：
Commodity表是我们系统中的一个大表，几年前在为该表创建Hash分区表时，当时的DBA在选择分区数时指定了100个分区：
查询各个分区的数据分布，我们可以看到，从分区37 ~ 64的28个分区的记录数大概是其他分区的两倍。由于100不是2的整数幂，所以Oracle的hash函数是无法保证数据是平均分布的。我们为该表添加一个新的分区COT_IND01_P101:
收集统计信息后查询新的分区记录数：
这时，我们可以看到，分区37中的数据被接近于平分到了分区37和101中。
监控增加分区过程中session锁的情况，我们发现期间有两个对象被以exclusive模式锁定了：
可以看到，分区37和100都被锁定了。锁定37分区是意料中的事，因为要从该表转移数据。那为什么要锁定第100个分区，也就是最后一个分区呢？
我的理解是：新增加分区的位置101是由原分区表的分区数100确定的，如果在增加分区的过程中允许对原表最后一个分区100作DDL操作，如coalesce操作，则新加的101分区就不一定是从原来的分区37分配数据了，101分区本身应该是新的第100分区，这样就引