标签：style blog io ar os sp 数据 on art
上次参加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
标签：style blog io ar os sp 数据 on art
原文地址：http://www.cnblogs.com/LiaoYe/p/4113619.html
