什么时候用表压缩较好呢？

    这个的确是，很多时候都需要具体问题具体分析收起

回复 9# freebile


     任何技术，都有自己的两面性，都有自己适用的场景  :)收起

还有一点就是数据的分布，如果大数据量中，数据的分布重复性很低，压缩效果并不明显，我之前遇到过一个表五十多亿条数据，但是重复性很低，压缩后并没有明显变化，SELECT的效率貌似提高了一点点，但是LOAD的效率就明显降低了，因为要做REORG和RUNSTATS，这些相比不压缩的表要稍微更耗时一点。收起

DB2 的行压缩为用户数据的存储和访问提供了更加有效和便捷的方式。通过使用行压缩技术，一方面可以节省存储成本，另一方面对于 I/O 是瓶颈的系统来说，由于压缩能使相同的数据页上存放了更多的用户数据，进而在数据访问时可以减少 I/O 次数，从而提高系统性能。然而，由于压缩和解压需要而外的 CPU 资源，对于某些 CPU 作为瓶颈的系统而言，压缩或许不是很好的选择。收起

嗯，大家一般多大的库会去做压缩呢？收起

这么说吧，因为压缩是用CPU换取内存和硬盘。压缩和解压都要消耗cpu，但相应减小了硬盘IO和容量，同时数据小了，内存存放的数据也就变多了。
就需要自己对实际情况进行平衡。
大多数情况来说压缩是有利的，但是CPU吃紧的时候就不推荐了。收起

表压缩适用于"重复模式"的大型表, 比如数据类型的缺省值或null都不会存储在磁盘上, 较少的数据页存储更多的数据, 可以将更多的逻辑数据高速缓存在缓冲池, 提高查询速度,减少i/o收起

杀猪焉能用牛刀。   :)

当数据量特别大，上10G左右，可以启用表压缩，节省空间，提供io的效率。收起

内存、cpu、存储都不吃紧
几千万的表导出后数据大约几G，也没觉得很大。。。
DB2有些好的特性，但是不知道什么时候适合用收起

硬盘吃紧的时候（容量、IO）；
内存吃紧的时候；
CPU比较充足的时候。至少要几M的表吧，因为压缩字典大小也会有几K到几十K。收起