*我在 SO 而不是 SF 上询问这个问题，因为我是一名开发人员，并且对数据访问性能方面感兴趣，而不是管理方面。
我一直在尝试研究/学习 TABLE | INDEX ... ROW | PAGE 压缩的基础知识。关于如何实现这些功能的信息非常丰富，我知道基本概念是，虽然您使用的 CPU 稍多，但节省的 I/O 却微不足道。但是，我找不到非常详细的解释，说明何时应该使用，何时不适合使用以及何时使用页面 v 行。即使在我读过的几本关于数据库架构性能调优的书中（他们似乎只是继续谈论它有多棒，然后掩盖了内部基础）。
即使这个SQLCAT文章MSDN 上的 (虽然是我找到的最深入的) 似乎并没有真正公正地对待这个主题。我有一些粗略的想法，因为在具有大量更新和插入的重型 OLTP 应用程序中，CPU 损失可能比 I/O 收益更为严重。
如果有人能给我提供一个很好的解释或者给我指出一些详细的文献，我将不胜感激。
提前致谢
答案1
理论上，如果您的数据库发出大量数据 IO，页面和行压缩会有所帮助。经过良好调整的 OLTP 应用程序将整个数据库放入内存中，只需要为预写日志写入日志并在检查点刷新脏页（请注意，在典型的 OLTP 中，页面在刷新之前会被多次弄脏），因此 OLTP 应用程序可能会因压缩而出现性能下降。这使压缩成为 DW/OLAP 阵营，并且压缩的好处会随着压缩率的提高而增加（某些数据比其他数据更易压缩）。
实际上，我注意到，平均 OLTP 工作负载实际上也受益于压缩。除了减少 IO 之外，压缩的行格式对于大多数数据（数字和固定长度字段）来说都明显更窄，这增加了内存密度方面的好处（更多行可以容纳在更少的页面中，使用更少的内存，更少的 TLB 未命中，从更少的缓存行中读取更多数据等等）。当 OLTP 负载转向更高端的范围时，情况就会发生变化（+16 个内核，强大的 IO 子系统能够处理 1000 次 IOPS，RAM 非常充足，以至于不需要任何页面读取后预热等等）。在这些高端系统上，压缩开始产生可衡量的影响并降低性能。
因此我想说问你自己这些问题：
- 我的部署机器是否能将整个未压缩的数据库放入内存中，并且有足够的空间？如果是，那么压缩的情况就会大大减弱。
- 我的数据可压缩吗？数字字段、固定长度列是可压缩的（行压缩）。Unicode 数据大多数情况下是可压缩的。页面上的重复值是可压缩的（页面压缩）（例如，在索引顺序相近的行簇上重复的值的长公共前缀）。请注意，页面压缩意味着行压缩。
- 我的读取与写入比率是多少？压缩对写入的影响更大。读取影响较小（压缩页面可以在第一次读取后从内部解压缓存结构中响应）。
- 你的数据量是否巨大？这是一个阈值，超过这个阈值，数据大小（例如备份文件的大小）的管理成本就会变得非常大，可以考虑使用压缩来节省那空间，即使这会影响性能。
但最终我们无法猜测。测量。在预期的部署硬件上进行测量，数据大小接近实际情况和您预期的负载。