在DB2数据库的存储优化实践中，压缩是一项绕不开的技术。面对不断增长的表格数据，直接扩容磁盘会带来更高的硬件成本和更慢的备份恢复速度。DB2提供了两种主要压缩机制：行压缩（Row Compression）和页压缩（Page Compression）。二者虽然都以减少物理存储为目标，但在压缩粒度、CPU消耗、适用负载等方面存在明显差异。错误选择压缩方式可能导致CPU飙升却收不到预期的空间节省效果。本文将分别剖析行压缩与页压缩的实现原理、启用方式及性能表现，并给出在不同业务场景下的选择建议。
一、DB2存储结构与压缩的基本定位
在深入两种压缩之前，需要先理解DB2的存储层级。DB2将数据组织在表空间中，表空间又由固定大小的页（Page）构成，页是DB2进行磁盘I/O的最小单位。每条记录以行（Row）的形式存放在页内。当一张表包含大量重复字符串或相似数据时，未压缩存储会浪费页内空间，导致缓冲池中能容纳的有效数据变少，进而增加物理读。压缩技术的本质是在不同粒度上消除冗余字节：行压缩着眼于单行内部及行与行之间的重复模式，页压缩则把整个数据页当作一个连续字节流进行压缩。
行压缩与页压缩并不是互斥的。DB2允许在行压缩的基础上再启用页压缩，形成两级压缩。但这种组合会带来额外的CPU开销，需要根据数据特征进行权衡。理解两者的工作粒度，是合理配置压缩策略的前提。
二、行压缩：基于字典的重复模式消除
行压缩的核心思想是静态字典。DB2通过扫描表数据，找出频繁出现的字符串模式（例如状态码、城市名、固定前缀等），生成一个压缩字典。字典中的每个模式会被替换成一个更短的符号，数据行存储时引用这些符号而非原始字符串。行压缩的字典生成通常需要执行REORG或INSPECT操作，DB2会根据采样数据构建字典并持久化到系统目录中。
启用行压缩的SQL示例如下：
-- 创建表时启用行压缩
CREATE TABLE sales_order (
order_id BIGINT NOT NULL,
customer_id BIGINT,
status VARCHAR(20),
city VARCHAR(50),
create_time TIMESTAMP
) COMPRESS YES;
-- 对已有表启用行压缩
ALTER TABLE sales_order COMPRESS YES;
-- 构建压缩字典
REORG TABLE sales_order RESETDICTIONARY;
行压缩的优点在于CPU开销相对较低，因为压缩和解压过程主要涉及字典查找。对于OLTP系统中大量短事务和高并发查询，行压缩可以在不明显增加响应时间的情况下节省20%到50%的存储空间。但行压缩的效果高度依赖数据重复性。如果列的值接近唯一，例如主键、时间戳或随机生成的订单号，字典无法找到足够多的重复模式，压缩收益会非常有限。此外，当数据分布发生变化时，旧字典可能不再匹配新增数据，需要定期执行REORG来重建字典以维持压缩效率。
行压缩还有一个隐性成本：被压缩的行在缓冲池中仍保持压缩状态，这有利于缓存更多行。但在某些需要整行扫描的计算场景中，解压操作会带来额外CPU指令。因此，对于已经存在大量计算密集型SQL的表，需要先评估解压开销是否会抵消I/O节省。
三、页压缩：整页级别的透明压缩
页压缩的粒度更粗，它以整个数据页为输入，使用通用无损压缩算法（如LZ类算法）对页内全部字节进行压缩，然后将压缩后的数据写入磁盘。从应用和SQL执行的角度看，页压缩对查询完全透明：数据页在从磁盘读入缓冲池时自动解压，缓冲池中保留的是未压缩的页；当页被刷出到磁盘时自动压缩。页压缩不需要构建行级字典，也不需要针对每张表执行特定的REORG操作来维护压缩元数据。
启用页压缩通常与表空间属性相关。对于新表空间，可以在创建时指定压缩；对于已有表空间，可能需要重建表或移动表到压缩表空间。示例如下：
-- 创建启用页压缩的表空间（以DB2 LUW为例）
CREATE TABLESPACE ts_compress
MANAGED BY AUTOMATIC STORAGE
USING STOGROUP IBMSTOGROUP
PAGESIZE 16K
COMPRESS YES;
-- 将表移动到压缩表空间
ALTER TABLE sales_order USING TABLESPACE ts_compress;
页压缩的优势在于它不依赖业务数据的重复模式，即使行内字符串完全随机，只要页内字节流存在局部相似性（例如相同的数据类型编码、时间戳前缀、填充字符等），就能获得不错的压缩率。对于数据仓库、归档表、日志表以及大批量加载场景，页压缩通常能实现50%到70%甚至更高的空间节省。由于压缩发生在I/O层，查询优化器感知不到数据页被压缩，执行计划不会因此改变。
不过，页压缩的CPU开销高于行压缩。每次物理读和物理写都要进行完整的页级解压或压缩，页大小越大，单次操作的数据量越多。在高并发OLTP环境中，如果缓冲池命中率很高，页压缩带来的I/O节省有限，而CPU成本会持续存在。另外，页压缩会增加备份文件中压缩页的格式复杂度，某些第三方备份工具可能需要额外适配。
四、行压缩与页压缩的区别与选择
为了更直观地理解二者差异，可以从几个维度进行对比。行压缩的压缩粒度为行，依赖字典和重复模式，CPU开销中等，适合OLTP高并发事务表；页压缩的压缩粒度为页，使用通用压缩算法，CPU开销较高，适合批量分析、归档和日志类数据。在空间节省上，页压缩通常优于行压缩，但这一点并非绝对。当一张表存在大量跨行重复值时，行压缩甚至可能接近页压缩的效果，而CPU成本更低。
选择策略可以遵循以下原则：如果业务以短小、高频的增删改查为主，并且表中有明显的重复字段（如状态、类型、地区），优先启用行压缩。如果表数据量大、更新频率低、主要用于报表查询或法规归档，优先考虑页压缩。如果表的数据特征兼具两者，可以先启用行压缩，观察一段时间后的压缩率和CPU使用情况，再决定是否叠加页压缩。需要避免在同时存在高并发写入和大量随机更新的表上盲目开启页压缩，因为每次更新都可能触发页解压和重新压缩，导致写放大。
监控压缩效果应当成为日常运维的一部分。DB2提供了表函数和系统视图来查看表级压缩信息。例如，通过SYSCAT.TABLES中的COMPRESSION列可以查看行压缩状态，通过ADMIN_GET_TAB_COMPRESS_INFO表函数可以获取压缩前后的大小和压缩率。定期查看这些指标，并在数据分布变化后重建行压缩字典，是保持压缩收益的关键。
五、压缩技术的运维注意事项
压缩不是一次性配置后就可以忽略的。行压缩字典需要与数据保持同步。当大量新数据插入后，旧字典可能无法有效压缩新的数据分布，导致表空间膨胀。此时需要执行REORG TABLE ... RESETDICTIONARY来重新生成字典。页压缩虽然不需要字典维护，但建议定期执行REORG以回收被删除记录占用的空间，否则压缩页中会残留碎片。此外，压缩对备份和恢复的影响也值得关注。启用压缩后，备份文件的体积通常显著减小，备份和恢复时间缩短，但恢复时需要消耗更多CPU进行解压。对于需要快速恢复的关键系统，应在恢复测试中评估实际解压耗时。
监控CPU利用率是另一个重点。压缩带来的CPU成本往往难以直观感知，但可以通过对比启用压缩前后的SQL平均CPU时间和系统总体CPU使用率来判断。如果发现CPU成为瓶颈，而存储节省收益不明显，可以考虑关闭压缩或改用更轻量的压缩级别。DB2部分版本还允许在表空间级别调整压缩算法或页大小，以适应不同的硬件环境。
综上，行压缩和页压缩是DB2存储优化的两种互补手段。没有一种压缩方式适合所有场景，合理的做法是基于表的数据特征、访问模式和硬件资源，选择一种或组合使用。通过持续监控和定期维护，才能在存储成本、I/O性能和CPU负载之间取得平衡。