上周我写了一篇博文，里面有一点关于分区表的论述（）。但是我发现我少写了一点，在你的查询条件和分区列没有太大关系的时候，分区表不会帮助你提高效率。

     

图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也是可以理解的吧。

      有什么不妥之处，请大家留言指正。