![何时需要/不需要在 mssql server 中进行索引和表压缩](https://linux22.com/image/557340/%E4%BD%95%E6%97%B6%E9%9C%80%E8%A6%81%2F%E4%B8%8D%E9%9C%80%E8%A6%81%E5%9C%A8%20mssql%20server%20%E4%B8%AD%E8%BF%9B%E8%A1%8C%E7%B4%A2%E5%BC%95%E5%92%8C%E8%A1%A8%E5%8E%8B%E7%BC%A9.png)
*我在 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 数据大多数情况下是可压缩的。页面上的重复值是可压缩的(页面压缩)(例如,在索引顺序相近的行簇上重复的值的长公共前缀)。请注意,页面压缩意味着行压缩。
- 我的读取与写入比率是多少?压缩对写入的影响更大。读取影响较小(压缩页面可以在第一次读取后从内部解压缓存结构中响应)。
- 你的数据量是否巨大?这是一个阈值,超过这个阈值,数据大小(例如备份文件的大小)的管理成本就会变得非常大,可以考虑使用压缩来节省那空间,即使这会影响性能。
但最终我们无法猜测。测量。在预期的部署硬件上进行测量,数据大小接近实际情况和您预期的负载。