SQL 数据库压缩通过减少磁盘空间节省存储，但增加 CPU 开销并影响查询性能；行压缩适合 OLTP 高频更新表，页压缩适合读多写少高重复数据表，列存储压缩适用于分析型宽表，备份压缩可减小文件体积但延长备份时间。
SQL 数据库的压缩机制主要通过减少数据在磁盘上的物理存储空间来实现存储节省，但会带来一定的 CPU 开销和潜在的查询性能变化。是否启用、压缩哪一层（行、页、列或备份）、以及压缩对象（表、索引、备份文件）的选择，直接影响节省比例与性能表现。
行压缩与页压缩：适用场景与开销差异
行压缩（ROW）通过简化数据类型存储格式（如用变长表示固定长度字段、去除空值占位）降低空间占用，CPU 开销较低，适合 OLTP 类高频更新的小事务表。页压缩（PAGE）在行压缩基础上增加前缀压缩和字典压缩，节省率更高（通常 20%–50%），但压缩 /解压 需更多 CPU 资源，更适合读多写少、数据重复度高的历史表或维度表。
- 行压缩对 INSERT/UPDATE 影响小，几乎不影响锁等待时间
- 页压缩在数据页首次填满并触发压缩时产生瞬时 CPU 峰值，频繁更新可能导致页拆分加剧
- SQL Server 中可通过 ALTER TABLE … REBUILD WITH (DATA_COMPRESSION = ROW) 在线启用
列存储压缩：面向分析场景的高密度压缩
列存储索引（Columnstore）天然按列组织、编码 和压缩，尤其擅长处理重复值多、数值规律性强的宽表（如事实表）。其压缩率常达 70% 以上，且支持批量执行提升扫描性能。但不适用于主键查找、短事务更新等点查密集型操作。
- 聚集列存储索引（CCI）默认启用字典 + 位图 + 行程编码等多种压缩算法
- 非聚集列存储索引（NCCI）可与行存储表共存，适合混合负载场景
- 删除 / 更新操作会先写入增量行组（delta store），需手动运行 ALTER INDEX … REORGANIZE 合并压缩
备份压缩：零存储冗余，但延长备份时间
备份时启用压缩（BACKUP WITH COMPRESSION）能显著减小备份文件体积（通常缩小 50%–80%），降低存储成本和网络传输耗时。该过程由 SQL Server 引擎在备份流生成阶段完成，不依赖底层存储压缩，也不影响源数据库运行状态。
- 压缩备份需额外 CPU 资源，备份耗时可能增加 10%–30%，但恢复时间通常缩短（因 I / O 量减少）
- 可在实例级默认开启（sp_configure ‘backup compression default’）或语句级控制
- 注意：TDE 加密后的备份无法再被 SQL Server 备份压缩，需权衡安全与空间效率
实际应用中的关键权衡点
压缩不是“开就一定好”。真实收益取决于数据特征（重复率、类型分布、空值比例）、硬件配置（CPU 核心数与主频、I/ O 子系统能力）及负载模式（读写比、并发度、查询类型）。建议在非生产环境用真实数据集测试，重点关注压缩前后缓冲池命中率、PAGEIOLATCH 等待、CPU% 和典型查询响应时间变化。
- 监控压缩效果：查询 sys.dm_db_partition_stats 对比 compressed_page_count 与 page_count
- 避免对小表（
- 页压缩后若出现大量页拆分，可调大填充因子（FILLFACTOR）预留空间
