MSSQL 2008数据库压缩指南：行压缩、页压缩与实战步骤

我接手过的不少业务库都跑在MSSQL2008上，而且大多数时候是磁盘报警把问题推到我面前的：数据文件把D盘塞到只剩几个GB，业务部门在群里催，领导在旁边问。很多同行的第一反应是右键数据库做“收缩”，收缩完物理文件确实小了一点，但下次业务高峰一来文件又涨回去，反复收缩还会把索引搞出一堆碎片。真正能持续省空间、而且对查询性能有正向作用的，是数据库压缩。

这篇文章不打算把联机文档抄一遍，而是准备把我做MSSQL2008数据库压缩的完整思路写出来：怎么评估值不值得压、行压缩和页压缩到底差在哪、实操命令怎么写、压完之后怎么维护，还有我实际踩过的坑。适合正在管老库的DBA、运维，以及想从存储成本上动点心思的同学参考。先提醒一句，文章里所有压缩操作都建议在维护窗口内做，别在业务高峰期手痒。

1. 先别急着压缩：空间告急时的正确应对顺序

1.1 三种“压缩”一字之差，别搞混

打开搜索引擎搜“MSSQL2008数据库压缩”，结果能搜出一堆完全不一样的东西。我见过有同事对着Windows磁盘管理里的“压缩卷”研究半天，想用它把C盘空间倒给D盘，还有人在数据库属性里点“收缩数据库”，然后问我为什么收缩完了性能反而变差了。这几个“压缩”根本是几码事，先分清：

很多人的习惯是空间一满就收缩数据库，这个操作本质是把文件尾部的空页搬走，但数据页本身没有任何变化。收缩完之后索引碎片率可能一下子飙到百分之几十，查询性能不升反降。我现在的原则是：能不用收缩就不用，宁可先把索引重建一遍再收缩，顺序绝对不能反。

Windows分区压缩更不建议碰。SQL Server的数据文件是随机读写为主，分区压缩会让底层文件系统在每次IO时都做额外的压缩和解压，CPU开销和IO延迟都会恶化，最坏情况是数据库整体变慢。如果磁盘真的紧张到需要动文件系统，优先加盘，别用这种手段硬撑。

1.2 什么样的表压缩收益最大

判断一张表值不值得压，先看这几个特征：行数多、单行宽度大、大量列经常是NULL或0、列值重复率高、有宽字符串列而且前缀雷同。比如订单流水表、日志表、状态表这类，通常压缩收益非常明显。反过来，只有几百行的小表、全是text/image大对象溢出数据的表、或者CPU已经常年接近100%的库，做压缩要非常谨慎。

这里面有个反直觉的点：表占空间最大，不代表压缩收益最大。我做过的案例里，一张5GB的日志表压缩后能省到1.8GB，另一张8GB的历史订单表压缩后只省了不到1GB，因为它的数据分布本来就比较离散，重复值少，压缩算法使不上劲。所以“看起来大”和“压得动”是两回事，必须用工具算一遍才靠谱。

CPU也是个关键变量。数据压缩本质是用CPU去换磁盘空间和IO时间。如果系统瓶颈本来就在CPU上，压缩之后查询会更慢；如果瓶颈在磁盘IO上，压缩后往往有意外惊喜，因为每个查询扫描的数据页变少了。所以动手之前一定要看一眼机器的CPU基线。我用过的简单办法是看任务管理器、性能监视器里的Processor Time，如果日常已经稳定在80%以上，就不建议大规模压缩。

1.3 先做评估再决定，别拿生产库试错

判断能不能压，不要靠猜。MSSQL 2008自带一个存储过程叫sp_estimate_data_compression_savings，会对指定的表采样一部分数据，然后模拟执行压缩，告诉你大概能省多少空间。这个功能我在项目实施中基本是标配，任何一张表要压缩之前，先跑一遍这个评估，把数据摆到桌面上再决定。

sql复制EXEC sys.sp_estimate_data_compression_savings
    @schema_name = 'dbo',
    @object_name = 'Orders',
    @index_id = NULL,
    @partition_number = NULL,
    @data_compression = 'PAGE';

跑完之后关注size_with_current_compression_setting和size_with_requested_compression_setting这两列的差值。我自己的经验阈值是这样：节省比例低于20%，基本不值得动，为这点空间背上CPU开销不划算；20%到35%之间，看CPU余量和IO压力再定；高于35%，不用犹豫，直接做。这个存储过程需要读表数据做采样，有IO压力，别在业务高峰期对全库十几张表同时跑，挑空间占用Top 20的表一张一张来。

2. 行压缩与页压缩：MSSQL 2008压缩的底层原理

2.1 数据页与行存储：压缩前先弄懂空间去哪了

SQL Server存储数据的基本单位是8KB的数据页，每页有个96字节的页头，剩下的空间用来放数据行。如果没有压缩，一张表里定义了什么列类型，每行就固定占多大空间，不管这个值实际有没有那么长。以一张典型订单表为例，OrderID int占4字节，CustomerID int占4字节，Status tinyint占1字节，Remark varchar(500)虽然可变长，但如果很多行压根没填Remark，那部分空间就会留白。更浪费的是定长char(100)这样的列，哪怕里面只存了5个字符，它还是占100字节。

行压缩的思路就是改变这个“固定长度”逻辑：能省则省，实际有多少有效数据就存多少。页压缩则更进一步，不光管单行，还管整页数据里的重复模式。两者的目标都是让一个8KB页面里塞下更多行，从而减少整张表占用的页面数量。页面少了，扫描和读取的IO自然就少了，这是压缩能带来性能提升的根本原因。

2.2 行压缩：把“固定长度”变成“实际长度”

行压缩对单行数据做优化，规则可以记成四句话：NULL和0不占用空间；整数和decimal等定长数值只保存有效字节；字符串列去掉尾部空格；每行增加少量元数据用来记录这些变动。比如int类型的值1，正常要占4字节，行压缩后只存1个有效字节；如果某个int列是NULL，那它在行里连1个字节都不占。

我在生产环境里做过一个小实验：一张表有30个列，其中10个列经常为NULL，还有几个状态列只有0和1两个值。压缩前单行占大约180字节，行压缩后单行降到40字节左右，数据页数直接少了三分之二。这不是个例，凡是“列多、空值多、数值小”的表，行压缩效果都会很好。

代价是什么？每条记录要额外留几字节的元数据，而且存储引擎在读写每一行时要做解压和压缩的动作，CPU开销增加。所以如果表里的行非常短，比如只有两个int主键列，每行节省的那点空间可能被元数据抵消掉，压缩完不降反升也有可能。

2.3 页压缩：前缀压缩和字典压缩怎么省出大空间

页压缩是行压缩的超集，它先把整页数据做行压缩，然后再套两层优化。

第一层是前缀压缩。数据页里如果有连续多行的同一列值有相同前缀，公共前缀只保留一次，后面的行只保留差异部分。最典型的是URL字段、文件路径、长地址这类字符串，比如https://www.example.com/order/1001和https://www.example.com/order/1002，前缀几乎一样，页压缩后相同部分只存一份，后面每行只存末尾几位。

第二层是字典压缩。页里如果出现大量完全相同的值，比如几十行的Status都是'PAID'，页压缩会把这些值塞进一个页面级字典，行里只存字典项的编号。这个编号通常很短，存储成本远低于原值。所以那种“某列枚举值不超过十几种”的表，页压缩效果会非常好。

页压缩和行压缩的实际选择，我给个粗暴结论：数据重复度高的表用页压缩，数据相对离散的表用行压缩。页压缩省得更多，但CPU代价也更大。如果拿不准，sp_estimate_data_compression_savings可以分别对ROW和PAGE跑一次，对比一下再定。另外，索引页也能压，聚集索引和非聚集索引的叶子页、非叶子页都支持压缩，不要只盯着表数据。

2.4 为什么有时压缩后反而变大

压缩不是玄学，它确实有“反向优化”的可能，主要原因是页压缩需要额外存储字典和前缀信息。如果一张表只有几千行，一共没几个页面，字典结构反而可能占到不少比例；又或者整张表每行只有一两个很短的定长列，行压缩省下的空间还不够填行头元数据。这种时候评估结果会显示负数，意思是压缩后比现在更大。

还有一个必须注意的点：在MSSQL 2008里，text、ntext、image以及varchar(max)、varbinary(max)溢出到LOB页的数据不会参与压缩。也就是说，如果大字段是藏在数据页外的，压缩对它基本没有效果。FILESTREAM列更直接，文件存在NTFS文件系统上，数据压缩根本管不到。所以遇到大量大对象数据的表，评估函数跑出来的节省比例都不会太好看，别硬压。

3. 实操落地：从评估、执行到验证的完整压缩流程

3.1 摸底：找出库里最占空间的对象

动手压缩之前，先搞清楚库里的空间都花在哪些对象上。我习惯用一条DMV查询把用户表按占用空间排个序，重点关注Top 20。

sql复制SELECT TOP 20
    OBJECT_NAME(ps.object_id) AS TableName,
    SUM(ps.reserved_page_count) * 8.0 / 1024 AS ReservedMB,
    SUM(ps.used_page_count) * 8.0 / 1024 AS UsedMB,
    SUM(ps.row_count) AS RowCount
FROM sys.dm_db_partition_stats ps
WHERE OBJECT_NAME(ps.object_id) IS NOT NULL
GROUP BY ps.object_id
ORDER BY ReservedMB DESC;

这个查询返回的是逻辑占用，单位是页，乘以8再除以1024就得到MB。重点是看两张表之间的大小差距，别被绝对值带偏。跑完这步，你心里就有了一张“最容易动手的表”候选清单。顺便说一句，这条查询本身很轻，不会对库造成明显压力，白天也能跑。

3.2 用系统存储过程估算压缩收益

针对候选表，逐张跑sp_estimate_data_compression_savings。如果表上有多个索引，@index_id = NULL会一次性评估所有索引；如果只想看聚集索引，可以指定具体index_id。默认情况下@partition_number = NULL会评估所有分区，返回结果按分区展开。

跑完看结果列：

• size_with_current_compression_setting：当前实际占用。
• size_with_requested_compression_setting：如果启用了目标压缩类型，预计占用。
• sample_size_with_current_compression_setting：采样部分当前占用。
• sample_size_with_requested_compression_setting：采样部分目标占用。

我通常把PAGE和ROW各跑一遍，然后拿两张结果的差值做对比。如果PAGE比ROW省得不多，就选ROW，因为它CPU代价小；如果PAGE明显多省30%以上，愿意多花CPU就上PAGE。还要注意，这个存储过程会做数据采样，对IO有一定消耗，建议在业务低峰跑，并且一张接一张地跑，别并发。

3.3 执行压缩：GUI和T-SQL双路线

MSSQL 2008企业版和开发版支持数据压缩，SSMS里也提供了图形化向导。操作路径是：右键目标表 -> 存储 -> 管理压缩 -> 向导会引导你选择行压缩或页压缩，并可以预览评估结果。这个向导在表数量少的时候很方便，但表多了以后效率太低，而且生产环境里我基本不靠图形界面操作，全部用脚本走，可审计、可重复。

T-SQL的核心语法有三种场景。

第一种，新建表时直接指定压缩：

sql复制CREATE TABLE dbo.OrdersNew (
    OrderID INT NOT NULL,
    OrderDate DATETIME NOT NULL,
    Status TINYINT NOT NULL,
    Remark NVARCHAR(500) NULL
)
WITH (DATA_COMPRESSION = PAGE);

第二种，对已有表启用压缩。这里注意，修改表压缩状态本质是重建表，生产环境务必备份：

sql复制ALTER TABLE dbo.Orders REBUILD WITH (DATA_COMPRESSION = PAGE);

第三种，只重建某个索引并设置压缩：

sql复制ALTER INDEX IX_Orders_OrderDate ON dbo.Orders
REBUILD WITH (DATA_COMPRESSION = PAGE);

如果是分区表，可以对指定分区做压缩：

sql复制ALTER TABLE dbo.Orders REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = PAGE);

执行压缩时，2008企业版支持ONLINE = ON方式在线重建，减少锁表时间；标准版不支持在线，必须停应用窗口执行。操作前建议把受影响表上的所有索引列出来，规划好哪些索引需要一起设压缩，避免主表压缩了，非聚集索引还是未压缩状态，空间回收不彻底。

3.4 压缩完成后的验证与统计信息更新

压缩操作结束时，先用系统视图确认压缩状态真的生效了：

sql复制SELECT
    OBJECT_NAME(p.object_id) AS TableName,
    p.index_id,
    p.data_compression_desc
FROM sys.partitions p
WHERE p.object_id = OBJECT_ID('dbo.Orders');

data_compression_desc如果是PAGE或ROW，就说明压缩配置已经写到了元数据里。但比这个更重要的是空间前后对比，我会再跑一次sp_spaceused 'dbo.Orders'，把reserved和data字段和压缩前的快照对比，确认实际页面有没有降下来。

压缩本质上是一次大规模的数据重写，统计信息在这过程中很可能已经过时。如果压缩完之后查询计划突然变差，十有八九是统计信息没跟上。所以我的固定动作是压缩后立即更新统计信息：

sql复制UPDATE STATISTICS dbo.Orders WITH FULLSCAN;

这一步不值钱，但能避免很多诡异的性能问题。

4. 压缩不是一锤子买卖：监控、维护与性能跟踪

4.1 页压缩会慢慢“过期”

很多人做完压缩，看空间降下来了就拍屁股走人，隔了半年回来发现表空间又悄悄涨回去了。这里有个关键机制：页压缩的效果会随DML操作逐渐退化。

原因并不复杂。页压缩里的前缀压缩和字典压缩，是在REBUILD的时候对整个页面做一次重新组织。之后新插入的数据行也会走压缩逻辑，但已经生成好的页面和字典并不会因为新数据到来就自动重新压缩。页面上原有的压缩布局逐渐被增删改破坏，字典里的项不一定来得及覆盖新值，于是平均每行占的空间开始回升。这是正常现象，不是故障。

想要压缩收益长期有效，就得周期性地重建压缩。对只读的历史归档表，一次压缩可以管好几年；对频繁增删改的流水表，可能一个季度就需要重建一次。具体周期没有标准答案，我一般结合下一节说的空间变化趋势来判断。

4.2 定期检查碎片与空间回弹

压缩之后，我建议建一个每周巡检的脚本，重点看两件事：索引碎片率和页面数变化趋势。

sql复制SELECT
    OBJECT_NAME(ps.object_id) AS TableName,
    ps.index_id,
    ps.avg_fragmentation_in_percent,
    ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
WHERE ps.avg_fragmentation_in_percent > 25
ORDER BY ps.avg_fragmentation_in_percent DESC;

如果碎片率超过30%，一般就要做索引重建；5%到30%之间可以做索引重组。但要注意，压缩表和普通表的维护逻辑不太一样：普通表重建成原来的压缩级别就行，如果页压缩已经退化导致空间回弹，重建时再显式指定一次DATA_COMPRESSION = PAGE，效果等同于重新做一次压缩。

更直观的做法是跟踪表的大小趋势。我每个月跑一次sys.dm_db_partition_stats，记录Top表的reserved_page_count。如果某张表的行数基本没怎么涨，但页面数却在持续增长，基本可以确定页压缩在退化，该安排重建窗口了。这个方法简单有效，比盯着监控大屏更实际。

4.3 查CPU变化来判断收益兑现

压缩到底值不值，最终要看业务负载的CPU和IO表现。我的常规做法是压缩执行前一周先记录CPU使用率的基线，压缩完成后继续观察一周，比较同时间段的平均值。如果CPU涨幅在10到15个百分点以内，而IO延迟和磁盘队列长度明显下降，那这笔交易是划算的。如果CPU直接被打满，或者查询响应时间不降反升，就要重新评估这张表是否适合保留压缩。

判断IO变化可以用Windows性能监视器看PhysicalDisk的Avg. Disk Queue Length和% Disk Time，也可以直接在SQL Server里看sys.dm_io_virtual_file_stats对应数据文件的读写延迟。数据文件所在磁盘的IO压力下降，是压缩生效最直接的信号。我个人经验是：压缩后如果一张大表的全表扫描类查询从原来的十几秒降到两三秒，那说明收益已经兑现了，CPU那点消耗完全值得。

5. 备份压缩、版本限制与我踩过的坑

5.1 备份压缩：数据库的备份也能再压一道

除了数据页压缩，MSSQL 2008还支持备份压缩。注意这跟数据压缩是两码事：数据压缩改变的是数据库文件内部布局，备份压缩改变的是备份文件的大小。两者不冲突，可以同时用。数据压缩把数据库文件变小，备份压缩再把备份文件进一步压缩，组合使用时存储收益非常可观。

备份时指定WITH COMPRESSION即可：

sql复制BACKUP DATABASE [YourDB]
TO DISK = 'D:\backup\YourDB.bak'
WITH COMPRESSION, INIT, STATS = 10;

还可以把这个行为设为实例默认值，后续所有备份任务都会自动压缩，不用每条命令都写：

sql复制EXEC sp_configure 'backup compression default', 1;
RECONFIGURE WITH OVERRIDE;

需要注意版本差异：在SQL Server 2008中，备份压缩功能主要面向企业版，到2008 R2之后标准版也可以使用。如果你的实例是2008标准版，执行备份压缩时报错，先查版本，别以为是语法写错了。备份压缩同样会消耗CPU，对备份窗口内的业务压力有影响，我通常把备份任务放到凌晨低峰时段，并限制并发，避免备份和业务互相抢资源。

5.2 版本和授权：为什么企业版才能做数据压缩

数据压缩在MSSQL 2008里是企业版和开发版的功能，标准版跑ALTER TABLE REBUILD WITH (DATA_COMPRESSION = PAGE)会直接报错。不少从低版本升级上来的运维第一次遇到这个问题，以为是命令写错了，其实纯粹是版本不支持。

如果你的库跑在2008标准版上，又确实缺空间怎么办？我见过三条实际可行的路：一是做历史数据归档，把超过保留周期的数据迁到归档库或者直接导出存储，这是空间收益最大也最保守的做法；二是用分区表做冷热数据分离，热点分区不压缩，历史分区压缩，2008支持分区级压缩，这个方案可以绕开“整表都要压”的限制；三是考虑升级实例版本或迁移到更高版本的SQL Server，这不仅是为了数据压缩，也是因为2008已经退出主流支持很久，安全风险得正视。

5.3 实际项目里的坑与规避方案

最后把我踩过的几个坑集中写一下，每一个都是真金白银换来的教训。

第一个坑：中途中断重建操作。有一年我在一张大表上执行压缩，因为窗口时间不够，我手贱把会话kill了，结果那张表被标记成suspect，整个库进入恢复模式，最后靠备份才救回来。后来我学乖了：压缩大表前先做完整备份，然后根据表大小估算执行时长，宁可少压几张表，也不做半截操作。重建是原子操作，中断会导致不可预知的后果。

第二个坑：日志文件暴涨。在完整恢复模式下，压缩一张大表会产生海量日志，磁盘空间不够的话重建会失败，甚至拖垮整个实例。我的处理方式是：维护窗口前把数据库切到简单恢复模式，压缩完成且验证无误后，再做一次完整备份，然后把恢复模式切回完整。这个操作有个前提——你清楚业务对数据一致性要求，切换恢复模式前必须有完整备份托底。

第三个坑：统计信息过期导致查询计划劣化。这个前面说了，压缩完不更新统计信息，优化器拿到的还是旧的密度信息，走错索引的事情很容易发生。现在我把UPDATE STATISTICS ... WITH FULLSCAN写成了固定动作，踩过一次之后就再没犯过。

第四个坑：先压缩又收缩，或者反过来。顺序很重要。正确做法是先重建索引、做压缩，把碎片和空间都整理干净，最后再收缩数据库文件。如果先收缩再压缩，数据文件会变得支离破碎，压缩时还会产生更多碎片，一次维护窗口处理不彻底，反而要返工。

第五个坑：只压表不压索引。很多表空间大头其实在非聚集索引上，只对聚集索引或堆做了压缩，非聚集索引还占着大块空间。所以压缩前把表上的所有索引列出来，逐个决定是否设置压缩级别，别漏。

我在实际项目里的固定动作是这样的：磁盘占用超过85%时启动评估，先跑Top 20表空间查询，再用sp_estimate_data_compression_savings逐张确认收益，压缩前完整备份，维护窗口内执行，压完更新统计信息，然后观察一周CPU和IO基线。这串流程看起来琐碎，但每一步都能规避一类问题，走过一轮之后，你对库里哪些表该压、哪些不该压，会有比任何工具都准的感觉。