SQL数据库页压缩机制_空间节省与CPU代价

页压缩通过前缀压缩和字典压缩节省空间，压缩率通常为30%–60%，但会增加INSERT/UPDATE、SELECT大范围扫描及索引重建时的CPU开销，需权衡空间与性能。

SQL Server 的页压缩（Page Compression）通过字典编码（Dictionary Encoding）和前缀压缩（Prefix Compression）减少数据页的物理存储空间，但会增加CPU开销。是否启用，需在空间节省与查询/写入性能之间权衡。

页压缩如何节省空间

页压缩在行压缩（Row Compression）基础上额外应用两步处理：

• 前缀压缩：扫描页内所有行的同一列（尤其是可变长列如 VARCHAR），提取公共前缀，存入页头的“前缀表”，行中仅保留后缀指针；
• 字典压缩：再扫描整页，将重复出现的值（跨列、跨行）提取到页头的“字典表”，行中用短偏移量替代原始值。

例如，一个含 1000 行、国家字段全为 'United States' 的订单表，启用页压缩后，该字符串只存一次，其余 999 行各占 2 字节指针，大幅降低存储占用。实际压缩率通常为 30%–60%，取决于数据重复度和列类型。

CPU代价主要出现在哪些环节

压缩与解压操作发生在数据页读写时，影响集中在以下场景：

• INSERT/UPDATE：写入前需构建前缀表与字典表，CPU 消耗随页内行数和列数上升；
• SELECT（尤其大范围扫描）：读取页后需实时解压，若查询涉及大量 I/O（如报表、聚合），CPU 成为瓶颈；
• 索引维护（如 REBUILD）：重建压缩索引时，需对每个页重复压缩流程，耗时显著高于非压缩索引。

实测显示，高压缩率表在 OLTP 写入密集场景下，CPU 使用率可能上升 15%–40%，而简单点查（利用索引精确定位单页）影响较小。

适用与慎用场景判断

不是所有表都适合页压缩，关键看数据特征与负载模式：

• 推荐启用：历史归档表、数据仓库事实表（高重复、低更新、常扫描）、宽表中存在大量 NULL 或重复字符串/数字的列；
• 不建议启用：高频 UPDATE 的事务表（如用户余额、会话状态）、列值高度随机（如 GUID、加密字段）、内存充足且磁盘成本低的环境；
• 可测试验证：对候选表启用压缩后，用真实负载跑压力测试，监控 Page compression CPU time/sec 和 Page reads/sec 变化，对比压缩前后查询延迟与资源消耗。

启用与验证的小技巧

启用页压缩无需停机，但会影响执行计划和锁行为：

• 使用 ALTER TABLE ... REBUILD WITH (DATA_COMPRESSION = PAGE) 启用，支持分区级粒度控制；
• 查看压缩效果：SELECT * FROM sys.dm_db_partition_stats WHERE object_id = OBJECT_ID('YourTable')，比对 used_page_count 压缩前后变化；
• 监控运行时开销：关注 PerfMon 计数器 SQLServer:Access Methods\Pages Compressed/sec 和 SQLServer:SQL Statistics\Batch Requests/sec 的相关性，识别 CPU 是否被压缩拖累。