数据量持续增长的背景下，DB2的表压缩功能成为许多企业控制存储成本的重要手段。DB2的压缩体系主要由两部分组成：基于压缩字典的静态压缩，以及在DB2 9.7之后引入的自适应压缩。两者名字听起来相似，工作原理和适用场景却有明显差异。如果混淆了这两种机制，可能会出现压缩率不达预期、CPU开销过高甚至空间不降反升的情况。本文将从原理、配置和实际选择三个层面，把这两种压缩方式讲清楚。
一、字典压缩的工作原理
字典压缩是DB2最经典的压缩方式，从DB2 9开始就广泛应用于LUW平台。它的核心思想是在表级别建立一个或多个压缩字典，字典中记录了该表数据页里高频出现的字符模式（symbol）以及对应的短编码。当一行数据被写入时，DB2会用字典中的短编码去替换数据里重复出现的字符序列，从而缩短行的物理长度。
压缩字典是在执行IMPORT、LOAD或者REORG等操作时，对表数据进行采样后构建的。这意味着字典反映的是建字典那一刻的数据特征。如果后续写入的数据模式与采样数据差异较大，压缩率就会明显下降。DB2允许为一张表最多配置大约1000个符号条目，对于重复度高的数据，比如状态字段、地区编码、重复的字符串前缀，字典压缩往往能取得不错的压缩效果。
启用字典压缩的典型建表语句如下：
CREATE TABLE orders (
order_id BIGINT NOT NULL,
order_status VARCHAR(20),
region_code CHAR(4),
order_note VARCHAR(200),
created_time TIMESTAMP
)
COMPRESS YES;
需要注意的是，COMPRESS YES只是声明表允许压缩，字典的真正构建还需要通过REORG或者大批量数据加载来触发。可以用下面的语句检查字典是否已经生成：
SELECT TABNAME, COMPRESSION, ROWCOMPMODE FROM SYSCAT.TABLES WHERE TABNAME = 'ORDERS';
二、自适应压缩的机制与优势
自适应压缩可以理解为字典压缩的升级版，它在DB2 9.7中引入，内部包含两个层次：表级别的静态字典压缩，以及行级别的动态压缩。动态压缩不依赖预先构建的字典，而是对每一行数据实时应用类似LZ类的通用压缩算法，再结合页级别的索引压缩能力，因此能处理字典压缩无法覆盖的数据模式，比如重复度低但内部结构有规律的长文本字段。
启用自适应压缩非常简单，使用COMPRESS COMPRESSION ADAPTIVE子句即可：
CREATE TABLE order_logs (
log_id BIGINT NOT NULL,
log_detail CLOB(1M),
created_at TIMESTAMP
)
COMPRESS COMPRESSION ADAPTIVE;
-- 对已有表也可以在线修改
ALTER TABLE order_logs COMPRESS COMPRESSION ADAPTIVE;
自适应压缩的最大优势是自适应三个字。它不需要依赖某个时间点的采样数据，随着数据内容的变化自动调整压缩策略，因此在大批量更新、数据分布持续演进的场景下，压缩率比纯字典压缩更稳定。此外，从DB2 10.1开始还引入了行压缩的增强和页级压缩选项，可以进一步提升空间节省。
当然，天下没有免费的午餐。动态压缩需要对每一行进行实时计算，CPU开销明显高于纯字典压缩。在CPU资源紧张、并发查询极高的系统上，这一点必须在规划阶段评估清楚。
三、压缩率、性能与选择建议
从压缩率角度看，如果数据重复度极高且模式稳定，纯字典压缩就能达到很理想的效果，额外开启动态压缩带来的收益有限，反而增加CPU负担。反之，如果表中包含大量自由文本、备注、JSON或XML内容，自适应压缩通常能多节省百分之二十到五十的空间，具体数字取决于数据的熵值。
从查询性能角度看，压缩是一把双刃剑。压缩后每个数据页能容纳更多行，顺序扫描的IO次数减少，缓冲池的命中率往往提升，这对于分析型查询是利好。但解压缩发生在数据访问路径上，CPU消耗增加，对于高频小事务的OLTP系统，响应时间可能会有百分之几到百分之十几的波动。建议在上线前用真实工作负载做对比测试。
实际选择时可以参考以下原则：
- 数据仓库、历史归档表：优先使用
COMPRESS COMPRESSION ADAPTIVE，最大化空间节省，CPU开销在这种场景下通常不是瓶颈。 - 高频交易的OLTP核心表：谨慎评估，可以先尝试纯字典压缩，观察CPU和响应时间的变化，再决定是否升级到自适应压缩。
- 数据分布变化频繁的表：选择自适应压缩，避免静态字典失效后压缩率滑坡，也省去了定期重建字典的运维成本。
- 空间敏感但CPU受限的表：使用
COMPRESS COMPRESSION STATIC，只保留字典压缩，控制动态压缩的CPU消耗。
四、常见问题与运维注意事项
第一个常见问题是字典失效。纯字典压缩的表在大规模数据更新后，旧字典可能不再匹配新数据，压缩率逐渐恶化。处理办法是执行表重组并重建字典：
REORG TABLE orders RESET DICTIONARY ALL;
第二个问题是压缩带来的索引膨胀误解。表压缩并不会自动压缩所有索引，需要单独评估索引压缩。可以通过INSPECT工具估算压缩前后的空间差异，避免凭感觉做决策：
db2 inspect change tablespace USERSPACE1
keep dictionary reports compressed estimate table ORDERS;
第三个问题是压缩与备份恢复的配合。压缩表在备份时直接以压缩形式存储，备份文件更小，恢复速度也更快，因为需要写回磁盘的物理数据更少。但要留意解压缩发生在查询阶段，如果恢复后的系统立即承接高并发查询，需要预留足够的CPU余量。
总结来说，字典压缩和自适应压缩并不是二选一的对抗关系，而是静态与动态互补的两个层次。理解自己的数据特征和系统的资源瓶颈，再决定压缩层级，才能在存储成本与性能之间找到最合适的平衡点。