上周我写了一篇博文,里面有一点关于分区表的论述(http://www.cnblogs.com/wingsless/archive/2012/02/04/2338292.html)。但是我发现我少写了一点,在你的查询条件和分区列没有太大关系的时候,分区表不会帮助你提高效率。
图1
图2
我是按照area_id分区的,图1的执行计划:
图2的执行计划:
建立一张表,这张表的数据和test一样,但是没有分区,执行一下图1中的语句,查看其执行计划:
可以明显的看出来,分区表的执行计划多了一个PARTITION LIST ALL,明显增加了CPU的耗用。再看看图2中SQL在test111中执行的执行计划吧:
确实很明显,这里少了PARTITION LIST SINGLE,但是CPU的耗用却没有变,当然了,我这个表非常非常小,如果数据量超过千万级,那么就能看出好处了。
从上述对比中可以很明显的看出来,分区表的使用是要看实际应用的需求的。如果存储过程始终是按照某一条件对数据进行查询,就像是图2中那样,每次查询的时候总是要带上area_id,那么建表的时候就可以考虑按照area_id进行分区。但是如果你平时的查询没有什么规律可循,那么你分区了,也许好心办坏事。
为了这篇博文,小弟在此豁出去了,不停地插表,现在搞出了一张3145728的test表和test111表,两个表数据一样,test有分区,test111没有。再看看执行计划,首先是SQL:
SELECT * FROM TEST a WHERE a.item_id = 1
AND a.area_id = 290;
SELECT * FROM TEST111 a WHERE a.item_id = 1
AND a.area_id = 290;
然后是执行计划:
1
2
看看,用了分区表之后虽说CPU的COST增加了,但是ROWS和BYTES都有了十分可观的降低。再将表扩大一倍,分区表和非分区表的ROWS比达到了2159K:10M,而BYTES比也达到了 121M:594M,CPU COST比:14487:8847。上帝啊,分区表在降低读取量方面堪称出色,但是在增加CPU COST方面堪称令人发指。
以前看过盖国强的书,里面说优化SQL主要是降低其物理读。但是我想如果能降低这里的ROWS和BYTES,对于一个小机环境的数据库处理器来说,高一点的CPU COST也是可以理解的吧。
有什么不妥之处,请大家留言指正。
©著作权归作者所有:来自51CTO博客作者wingsless的原创作品,如需转载,请注明出处,否则将追究法律责任
ORACLE优化分区表oracle管理
2