测试以查看表何时适合压缩（行或页）

Question

有谁知道像这个页面https://columnscore.com/这样的工具，可以在其中确定一个表是否适合行或页压缩。

我也试图了解压缩的好处。我一直在阅读它，但仍然有这些问题。

1. 压缩会使缓冲区缓存中容纳更多 8KB 吗？数据何时变得未压缩，即在选择中？
2. 备份会变得更快吗？
3. 压缩广告cpu开销的原因是因为例如插入需要在插入之前被压缩吗？
4. 是否有充分的理由在不调查表的使用方式（即静态与易失性）的情况下压缩表。

一个同事开始压缩很多表（页）。我不知道这个决定背后的分析。我知道我们有时会在某些高峰时段等待资源信号量。我实际上不认为他知道他在做什么。我可以看到我们的 sos 调度程序收益等待略有增加。

我认为压缩会造成更大的伤害，现在维护任务似乎更多（例如备份、checkdb ......）。

Answer 1

有谁知道像这个页面https://columnscore.com/这样的工具，可以在其中确定一个表是否适合行或页压缩。

工具建议在这里是题外话，主要是因为可以有任意数量的答案，而且它们往往很快就会过时。也就是说，SQL Server 确实提供了一个内置过程来估计压缩所节省的空间，sp_estimate_data_compression_savings. 它不会尝试预测压缩对于整个工作负载是否是一个好的选择，而只是预测是否可以预期空间节省。它本质上是一个围绕 的包装器TABLESAMPLE，创建一个新对象并从那里推断出全尺寸。

压缩会使缓冲区缓存中容纳更多 8KB 吗？

如果压缩有效，则可以。页面在缓冲池中保持压缩状态。

数据何时变得未压缩，即在选择中？

当存储引擎级别以上的 SQL Server 组件需要处理数据时，数据将被解压缩。例如，索引扫描会将解压后的数据呈现给执行计划中的过滤器运算符。

下面的堆栈跟踪显示了在将数据呈现给查询处理器之前解压的一个示例（突出显示了存储引擎代码）：

您可以在Sunil Agarwal（当时是 SQL Server 工程团队的一部分）的Compression Strategies 中阅读有关此内容的更多信息。

备份会变得更快吗？

许多人报告说他们这样做了。直觉是持久存储上的压缩数据需要更少的 I/O 来读取备份。如果您的实例通常受 CPU 限制，您可能会看到备份速度较慢，因为解压缩所需的额外处理器工作超过了 I/O 加速。

压缩广告cpu开销的原因是因为例如插入需要在插入之前被压缩吗？

当然压缩会增加 CPU 开销，但这通常是可以管理的，因为选择数据压缩算法是为了效率而不是最终大小。请注意，数据压缩和备份压缩非常不同。备份压缩基于 gzip 压缩的一种变体，旨在以牺牲更多 CPU 使用率为代价实现非常好的大小缩减。

每次插入和更新都会产生至少一些数据压缩开销。这在PAGE压缩时更明显。SQL Server 也可能会在对该页面进行一定数量的修改后尝试重新压缩整个页面。

是否有充分的理由在不调查表的使用方式（即静态与易失性）的情况下压缩表。

这是主观的，取决于您当地的优先事项。一般来说，如果很明显会节省大量（和必要）空间，并且系统有大量空闲处理器时间可用，则可能会选择不进行详细测试而进行压缩。

一个同事开始压缩很多表（页）。我不知道这个决定背后的分析。

您应该与您的同事讨论理由。