许多人认为简单的问题都应该有简单的答案，比如“SQL Server数据库的备份压缩值不值得？”。简单的回答是：值得，但是这个值得也是有条件的。所以要更好地表达这个问题，我们应该这样来说：“怎样进行SQL Server备份压缩，才能得到更高的回报率”？

　　微软公司首次添加压缩数据库备份功能是在SQL Server 2008企业版中，在之后的所有版本中都包含这一功能，如2008 R2和2012。这个功能对于用户来说最大的吸引力就是节约成本：你可以免去使用第三方产品所带来的额外费用，也可以节约更多的磁盘空间，而且在传输压缩备份时所需要的带宽也相应地减少了。

　　但是在使用SQL Server作为数据仓库的企业中，还要考虑其他的一些影响。从积极的一面来看，尽管拥有压缩备份功能的SQL Server非常有限，但是它依然可以存储在许多版本的系统中。不过进行压缩就意味着会对数据库自身的性能造成影响，所以企业在使用这一功能时，要对利弊进行全面的评估：究竟是花更多的钱使用第三方压缩工具，还是为了节省成本而牺牲一定的性能来使用SQL Server自带的压缩功能。

　　数据库技术专家Vincent Rainardi最近在他的一篇博客中深入解读了压缩备份的成本效益问题。根据他的计算，对于大型数据库来说，I/O所节省的时间完全可以抵消进行压缩处理所用的时间。由于大部分数据库操作(特别是备份)都属于是I/O密集型操作，所以对于一个几TB的数据库来说，60%的压缩比将是一个非常诱人的数字。正如Rainardi的观点，DBA所能获得的效益不仅仅只是时间，而且进行备份所需要的存储空间也大大地减少，这意味着我们可以存储更多的数据，节省更多的带宽和金钱。

　　较为困难的部分是要确保我们在实际的生产环境中也能够得到持续的效果。Rainardi的实验相对于许多企业的数据库来说都是非常小规模的，而在一些BI分析或者数据仓库场景中，上亿行数据以及几百TB数据都是非常常见的。Unisys公司的一篇白皮书使用了一个2TB的数据库，这与我们日常所要维护的数据规模就比较接近了。

　　白皮书的作者这样写道：“在一些情况下，要达到整体的收益是有可能的，但是这并不容易。”他指出数据库压缩要权衡存储空间、I/O和整体性能几个方面的因素。举例来说，要进行压缩，就需要牺牲一些CPU来进行处理，从而导致性能降低。但是压缩后的备份数据可能在I/O方面的需求就有所降低了，因此用户需要权衡这两方面的因素，如果能够得到不错的效果，那就值得一试。

　　当使用备份压缩功能时候，我们需要弄清楚几个障碍。白皮书作者认为，虽然使用WITH COMPRESSION命令生成备份是一个非常简单的问题，但是CPU使用率的上升是比较明显的。他们使用了一个度量标准，叫做CPU秒(CPU-seconds)，即备份运行时间乘以平均CPU再乘以CPU的数量。而使用越多核芯越多插槽，压缩所造成的影响就越少。也就是说，微软建议使用资源管理器(Resource Governor)来限制备份使用超过平均值的CPU资源，不管你使用了多少核的CPU和插槽。