关于HASH分区

上次参加 oracle 的培训，老师讲到了利用10g 智能分区匹配可以极大地提高两个分区表的连接速度，对于这两个分区的要求就是必须采用相同的分区策略，最简单的实现就是两个分区表都采用 HASH 分区，并且 HASH 分区的分区数也必须是相同的。老师还提到对于 HASH 分区来说，分区的数量最好是 2 的幂，这样的效率会高一些。[@more@]

至于为什么分区的数量最好是2的幂这个问题，我一直也没有思考，就当个经验记下来了。前两天看一位大牛的BLOG也提到HASH分区的事情，仔细阅读之后才明白。HASH分区的个数会极大的影响HASH分区表的数据分布。也就是说，HASH分区个数为2的幂的时候数据会更加的平均分布在每一个分区中。

我做了一个简单的测试，只帖出简单的测试方法和结论。

测试方法：

1， 建立测试用HASH分区表

Create table sunwg (id varchar2(100))

Partition by hash(id)

(partition p1,

Partition p2);

2,插入测试记录

Insert into sunwg select rownum from dba_objects where rownum<17;

3，查询各个分区中的记录数

P1 rownum : select count(*) from sunwg partition (p1);

P2 rownum : select count(*) from sunwg partition (p2);

注意：在上面的表中我只插入了16条简单的记录，是为了测试方便，更加方便的得到测试的结论。不过，由于记录太少，所以即使采用合理的分区方式也不能避免数据分布的不平均。这个不平均是由于记录的问题产生的，分布方式本身是没有问题的。

测试结果：

1，分区数：2，记录数：16

Partition p1 rownum : 6

Partition p2 rownum : 10

2, 分区数：3，记录数：16

Partition p1 rownum : 5

Partition p2 rownum : 10

Partition p3 rownum : 1

P1 ===》P1 + P3

3，分区数：4，记录数：16

Partition p1 rownum : 5

Partition p2 rownum : 4

Partition p3 rownum : 1

Partition p3 rownum : 6

P4 ===》P2 + P4

我的测试一直做到partiton是8的时候，结果都很相似，就不贴出来了。

测试结论：

1， 对于HASH分区来说并不存在split partition的操作，仅仅存在add partition的操作。数据在各个分区的分布情况并不由我们控制，而是通过oracle中的hash函数来操作的，所以我们不能显示的指定某一个分区进行分裂。

2， 当我们对HASH分区进行add partition操作的时候，假设增加分区后的总分区个数为m，大于m的最小的2的幂是n，那么partiton m的数据是由分区（m – n/2）（某大牛的结论）。

3， 当我们确定合理的分区数量的之后，数据的分布完全由分区表中的数据本身决定。对于某些特定的数据来说，HASH分区后的效果可能并不好。数据的随机性越大，数据的样本量越大，HASH分区后的效果越好，因为数据有可能更加平均的分散到每个bucket中。

4， 最后需要说一点，虽然很简单，但却常常让人误会。对于分区个数为m的HASH分区表来说，无论期间经历了怎么样的过程（比如说先建立n个分区的HASH分区表，然后通过add partiton来达到m；还是直接建立一个分区数为m的分区表；）最后的结果都是一样。“殊途同归”！

1， 最后最后需要说的一点是，对于HASH分区表，drop partition操作是不可以的。

SQL> alter table sunwg drop partition p1;

alter table sunwg drop partition p1

*

ERROR at line 1:

ORA-14255: table is not partitioned by Range, Composite Range or List method

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

转载于:http://blog.itpub.net/8394333/viewspace-998044/