何时/不使用 mssql 服务器中的索引和表压缩

Question

*我在 SO 而不是 SF 上问这个问题，因为我是一名开发人员，并且对这方面的数据访问性能方面而不是管理方面感兴趣。

我一直在尝试对 TABLE | 的基础进行一些研究/学习。索引...行 | 页压缩。有大量关于如何实现这些功能的信息，我知道一些基本概念，即虽然您使用的 CPU 稍多，但节省的 I/O 可以忽略不计。但是，我没有找到一个非常详细的解释，说明何时应该在不适合使用时使用以及何时使用第 v 行。甚至在我读过的几本关于性能调优数据库架构的书中（他们似乎只是继续谈论它有多棒，然后掩盖了内部基础）。

即使是 MSDN 上的这篇 SQLCAT文章（虽然是我发现的最深入的文章），但似乎并没有真正解决这个话题。我有一些粗略的想法，因为在具有大量更新和插入的繁重 OLTP 应用程序中，CPU 损失可能会严重影响 I/O 的收益。

如果有人能为我提供一个很好的解释或为我指明一些详细文献的方向，我将不胜感激。

提前致谢

Answer 1

理论上，如果您的数据库发出大量数据 IO，则页面和行压缩会有所帮助。调整良好的 OLTP 应用程序适合内存中的整个数据库，只需要写入日志以进行预写日志记录并在检查点刷新脏页（请注意，在典型的 OLTP 中，页面在刷新之前会被多次弄脏），因此 OLTP 应用程序可能会因压缩而退化。这将压缩放在了 DW/OLAP 阵营中，压缩的好处随着压缩率的增加而增加（一些数据比其他数据更容易压缩）。

在实践中，我注意到平均 OLTP 工作负载实际上也从压缩中受益。除了减少 IO 之外，压缩行格式对于大多数数据（数字和固定长度字段）来说明显更窄，这增加了内存密度方面的好处（更多的行适合更少的页面，更少的内存使用，更少的 TLB 未命中，更多的读取来自更少的缓存行等）。随着 OLTP 负载向高端频谱移动（+16 核，强大的 IO 子系统能够达到 1000 秒的 IOPS，RAM 如此慷慨，以至于不需要任何页面读取后预热等），事情就会中断。在这些高端系统上，压缩开始产生可衡量的影响并降低性能。

所以我会说问自己这些问题：

• 我的部署机器是否可以将整个未压缩的数据库放入内存中，并有足够的空闲空间？如果是，则压缩的情况显着减弱。
• 我的数据可以压缩吗？数字字段、固定长度的列是可压缩的（行压缩）。大多数情况下，Unicode 数据是可压缩的。页面上的重复值是可压缩的（页面压缩）（例如，在按索引顺序关闭的行集群上重复的值的长公共前缀）。请注意，页面压缩意味着行压缩。
• 我的读取与写入比率是多少？压缩对写入的影响更大。读取影响较小（压缩页面可以在第一次读取后从内部解压缩缓存结构中响应）。
• 你的数据很庞大吗？这是一个阈值，在该阈值之后，数据大小（例如备份文件的大小）的管理成本变得显着，并且可以考虑进行压缩以节省该空间，即使它会损害性能。

但最终，我们将无法猜测。措施。在预期的部署硬件上进行测量，数据大小接近真实情况和您期望的负载。