从SQL Server 2005开始，在企业版和开发版中增加了一种叫做vardecimal的新存储格式，这个表级的选项会影响到decimal和numeric字段。当对值的精度要求低于字段可用精度，如在一个decimal(18,9)类型的字段中存储1.5这个数值时，存储上就需要有相应的压缩。从效果上来看，它就是一个varchar类型的数字型版本。

无论从哪方面来看，SQL Server 2008的数据压缩都与现在有着巨大的差异(尽管它依然支持或者说包括vardecimal类型)——引起这种差异的真相是，如果你对一个给定的table/index启用压缩功能，那么底层的row/page格式将不再相同——是的，就是这样，你听得没错——如果你使用压缩(ROW或者PAGE)，那么SQL 2008的row/page格式将不同于现有的格式(如果你只是在table/index上使用压缩的话)。因此，在SQL 2008中，有两种，没错，是两种可选row/page数据格式。你现在可能会想知道“那么，如果row/page格式改变了，那你们究竟是如何在这么短的时间内，依然有足够的时间去重新生成SQL Server所有需要识别这些格式的组件的呢?”答案就是我们不需要那样做——因为Storage Engine是SQL 2008中唯一一个需要知道新的row/page格式的组件。

行级压缩将大幅减少元数据所需的变量长度，较以前每个字段需要花费2个字节来存储，现在只要仅仅3个位。字段本身现在也变得更小，在整型字段中存储像1这样的数值，只需要一个字节，而大数值则最多只需要4个字节。

行级压缩则允许在行间共享共有数据。Chad首先谈到的两种技术就是列前缀和页字典：

假设你在一页的数据行中有一列数据有这些值：‘Chad’、‘Chadwick’、‘Chadly’、‘Chad’、‘Chadster’、‘Chadwick’和‘Chadly’(故意重复的数值)——正如你所见，有相当多的冗余‘前缀’数据在这一页的同一列的不同行中，是吧?因此，你最终可能会想到这样的一个场景：将列的前缀‘Chad’存储在CI结构中，每一个列的最后都指向这个前缀值，最后出现在磁盘上的值会像这样：‘’，‘1wick’，‘1ly’，‘1ster’，‘1wick’和‘1ly’。

所以，对于上述例子中的含有Chad的同列数值，在经过对“列前缀”值进行计算和存储后，你可能得到一个会含有如‘1ly’和‘1wick’这些值的页字典，而真正行内数值则极有可能看上去像这样：‘’、‘2’、‘3’、‘’、‘1ster’、‘3’和‘2’。通过这种方式，我们让原本需要大约25个字节来存储的行数据，减少到只要大约17个字节来存储，节省30%以上。

每一个页都是单独压缩的，前缀和字典也存储在页内。由于页是存储分配的原子单位，将半页压缩到四分之一页是没有任何意义的，所以，只有在页的内容快满的时候才会开始压缩处理。

在使用行和页压缩时还有一个性能权衡问题，因为CPU使用率会上升，但I/O使用率和内存占用会下降。

Backup Compression是2008的另一个特性，它是通过普通的文件系统型压缩技术实现的，对于给定的数据库，只有启用或者禁用，没有其它可调节选项。

虽然非企业版服务器可以恢复带压缩的备份，但这所有的压缩选项极有可能成为企业版专享选项。