使用Row compression和Page compression等表压缩是否有缺点，例如：
ALTER TABLE A
REBUILD WITH (DATA_COMPRESSION = PAGE) --or ROW
如果上面的命令可以利用sql查询的性能，那么我们为什么不在每次创建新表时都使用它，即使它可能不会影响数据页很少的表。
使用这个有什么缺点吗？
感谢
摘要：查看@paulbarbin的答案或查看本文的结论部分
正如我们所看到的，行级和页级压缩可以是强大的工具以帮助您减少数据占用的空间并改进执行速度，但以CPU时间为代价。这是因为行或页需要一个步骤来撤消压缩(或计算以及匹配散列)，并且这直接转化为计算时间。所以在部署行级或页级压缩时，执行一些类似的操作测试(欢迎您使用我的框架！)，看看它是如何发挥作用的在您的测试环境中。您的结果应告知您的决定-如果你已经被CPU限制了，你能负担得起部署这个吗？如果你的储藏室着火了，你能承受不着火的后果吗？
压缩确实会带来开销。需要额外的CPU来完成压缩，基于压缩的限制，您可能会发现收益小于痛苦。然而，据我所知，大多数人在大多数情况下都受益于页面压缩，并在特定情况下使用行压缩。我想说的是，在您的开发/测试环境中尝试一下，确定您的CPU成本和查询节约，并在有意义的情况下实现。
当对表应用页面级压缩时，也会应用行级压缩。页面压缩的好处取决于压缩的数据类型。涉及许多重复值的数据将比由更独特的值填充的数据压缩得更多。还有一件事，数据压缩改变了查询计划，因为数据被压缩在不同的页数和行中。存在检索压缩数据所需的额外CPU。我建议，只有当您有一个包含数百万条记录的大型仓库表，并且您/您的应用程序不需要频繁查询该表时，才使用压缩。当它是分区表时，您也可以使用分区级压缩。