昨天写了一下关于Oracle表压缩的问题（http://www.cnblogs.com/wingsless/archive/2012/09/23/2699309.html），由于时间原因没有具体的实验，只是使用了网上的资料，但是这并不是我的风格，因为网上资料直接拿来转载的多，自己原创的少。所谓事必躬亲嘛，做个实验。
有两张表，一张压缩（TEST_1）一张不压缩（TEST）。
首先看看占用空间的情况，查表的语句如下：
BEGIN FOR I IN 1 .. 50 LOOP INSERT /*+append*/ INTO TEST_1 SELECT * FROM DBA_OBJECTS; COMMIT; END LOOP; END; BEGIN FOR I IN 1 .. 50 LOOP INSERT INTO TEST SELECT * FROM DBA_OBJECTS; COMMIT; END LOOP; END;
下面看看空间占用的情况：
可以看到，压缩表确实在空间占用的减少上特别给力！只是原来大小的29%左右。这效果快赶上用rar压缩word文件和文本文件了。
接下来，查看一下select的效率。在执行计划出来之前要先analyze，因为只有analyze过的表，执行计划才能达到最准确的（http://www.cnblogs.com/wingsless/archive/2012/02/24/2367176.html）。
通过上面两张图片，可以发现，压缩表在查询的时候不管是CPU的COST还是Bytes都要较非压缩表小。从网上能查到的资料显示，压缩表在某些条件下是可以提高查询效率的，这句话看来是对的。但是压缩表会不会拉低查询效率我还不知道，暂时也没有发现实验的方法，以后发现了会继续实验。
大部分资料都显示，压缩表会影响插入效率。我又建立了一张表，数据很多很多，分别插入上述两张表中：
可以很明显的看到，压缩表的插入时间是非压缩表的将近两倍之多。这就很好的说明了压缩表的插入效率非常低下，建议对历史数据进行转移的时候选择在夜间使用人数较少，CPU较为空闲的时候进行。
如果是一个没有压缩过的表，压缩后效率如何？
有一张表叫做TEST_2，插入数据的方法和上面的TEST一样，它的大小为408MB。还有刚才那个test表，truncate之后再插入数据，不同的是这次加上了append。这样做为的是看看加了append是不是会增加存储空间，这属于拓展思维了吧。但是事实是TEST表也是408M。然后把两个表都压缩一下：
惊喜的发现使用append的表压缩起来更给力，这个现象是为什么呢，我个人猜测和使用了hint之后数据直接往队尾插是有关系的，我这个表是新建的，但是如果是生产系统上的那些表，常年更新着，应该会有很多碎片，常年使用hint的话估计会出现一些问题，尤其是空间被占用不好解除占用的问题。
test刚才被我转换成了压缩表，统计一下信息之后，更新一个数据看看是不是会像rar压缩一样，要更新一个文件，就要先把文件解压，然后再压缩。占用一定的存储空间。
UPDATE TEST T SET T.OWNER = 'OI' WHERE T.OWNER = 'SYS';
确实大了不少。现在弄一张非压缩表，不压缩数据，然后更新看看占用，现在TEST_2被我拿来测试，数据量是368MB，更新之，查看一下：
可以看到非压缩表并不会像压缩表那样在更新的时候占用额外的空间。
那么综上所述，压缩表的好处就是可以有效的降低存储空间的占用，还可以提升查询的效率，但是缺点也很明显，那就是会提高插入数据的时间，会在更新数据的时候占用额外的空间。可以看出来，压缩表更适合于数据仓库的建设，毕竟数据太多了，不得不考虑存储的成本，我以前的一家公司有一个客户，采用的办法就是把原始的文本数据文件刻到蓝光光盘里，50多一张盘，人家买得起。但是人家是备份数据，防止数据灾难的，数据压缩，非常适合数据仓库。