*我问这个不是SF，因为我是一个开发人员，对这个不是政府方面的数据访问性能方面感兴趣。
我一直在试图做一些研究/学习到表|的基础 INDEX …行| 页面压缩。 有关如何实现这些function的丰富的信息，我知道的基本概念，当您使用稍多的CPU时，保存I / O是微不足道的。 然而，我没有find一个非常详细的解释，当不适合利用和何时使用页面v行这应该被利用。 即使在几本书中，我也已经读过关于性能调优的数据库体系结构（他们似乎只是继续讨论它是多么伟大，然后掩盖了内部基础）。
即使是MSDN上的这个SQLCAT 文章 （虽然我已经find了最深入的内容）似乎并没有把主题正义化。 我有一些粗略的想法，比如在一个沉重的OLTP应用程序中，分配更新和插入，CPU处罚可能会比I / O中的收益更重。
如果任何人能够给我一个很好的解释或者指向我的一些详细的文学的方向，我将不胜感激。
提前致谢
理论认为，如果您的数据库发出重要的数据IO，则Page和Row压缩有帮助。 良好的调整OLTP应用程序适合整个数据库的内存，只需要写日志提前写日志，并在检查点刷新脏页（请注意，在典型的OLTP刷新之前，许多次的页面被弄脏），因此OLTP应用程序可能会看到压缩的退化。 这使得DW / OLAP阵营中的压缩成为可能，压缩效益随着压缩比的增加而增加（一些数据比其他数据更可压缩）。
实际上，我注意到平均OLTP工作负载实际上也受益于压缩。 除了减lessIO之外，对于大多数数据（数字和固定长度字段），压缩行格式显着更窄，这增加了内存密度方面的优势（更多的行适合更less的页面，更less的内存使用，更less的TLB未命中，更less的更less的读取caching行等等）。 随着OLTP负载向高端频谱方向发展（+16内核，能够达到1000s IOPS的强大IO子系统，RAM如此慷慨以至于不需要任何页面读取预热等），事情就会中断。 在这些高端系统上，压缩开始产生可测量的影响并降低性能。
所以我会问自己这些问题：
但最终，我们将无法猜测。 测量。 测量预期的部署硬件，数据大小接近实际情况和预期的负载。