在我的 OLTP 数据库服务器上，主要的性能瓶颈是 I/O。如果我压缩我的数据库，根据我的计算，压缩率将达到 60%。由于内存中的页面也有压缩数据，所以更多的数据可以存储在内存中，从而在很大程度上减少 I/O。在这种情况下，我是否会从更少的 I/O 中获得显着的性能优势？
答案1
这是由于一种资源有限（磁盘 I/O 不足）导致另一种资源（CPU 时间）无法使用的问题。最好的办法是增加更多磁盘 I/O，这样就可以充分利用服务器的所有性能潜力。
如果这对您来说不可行或不需要，那么我认为您应该启用压缩。您实际上将放弃“免费”资源（CPU 时间，您拥有太多），以获得更多限制资源（磁盘 I/O）。上面您写道“处理器很少超过 80%”；我认为这意味着您大多数时候有 20% - 40% 的可用 CPU。对于该服务器来说，启用压缩应该可以正常工作。
由于内存中的页面也有压缩数据，因此更多的数据可以存储在内存中，从而大大减少 I/O。
Mnn，这是正确的，但性能影响可能不会像您希望的那么大。这将取决于启用压缩之前和之后缓存数据集和“工作数据集”之间的比率。
请注意有 2 种压缩级别可供选择。也许仅启用行压缩对您来说是一个黄金折衷方案..？
答案2
如果您的数据很容易压缩（例如文本字段中的类似文本等），并且您有大量内存（为了不碰到交换文件），我可以肯定地说事情会变得更快。
硬盘确实是速度很慢的组件，所以任何可以避免它的方法都是有帮助的。
PS：此功能使用相当多的处理器，因此如果您的处理器使用率已经很高，请考虑到这一点。
答案3
您还可以选择压缩聚集索引而不是每个索引。这将减少索引查找对 CPU 的占用，但当您实际从聚集索引中获取数据页时，您应该会获得 IO 性能。
作为迁移到 SQL 2008 的第一步，我们在聚集索引上启用了页面压缩，以查看我们使用了多少 CPU。我们的速度提高了约 20%，但仍有大量 CPU 资源剩余（我们使用的是 4 x 四核处理器服务器），因此在下一个版本中，我们还将压缩所有其他索引。
很难预测您将从任何性能调整中受益多少，而解决方案始终是测试、测试、再测试。