孔夫子*_*孔夫子 11 data-warehouse sql-server compression sql-server-2012
我读过的一些关于 SQL Server 数据压缩的文献指出，写入成本增加到通常所需的四倍左右。这似乎也暗示这是数据压缩的主要缺点，强烈暗示对于只读存档数据库，性能将（除了少数例外）通过使用 100% 填充页面的数据压缩来提高。
数据压缩和其他方式之间的主要“变化”是什么（用于阅读）
出于此问题的目的，您可以将上下文限制为大型(> 1TB)数据库的PAGE 级压缩，但始终欢迎其他评论。
参考：
SQL Server 存储引擎博客（DW 场景显示压缩非常有利）
数据压缩：策略、容量规划和最佳实践
决定压缩内容的更详细方法涉及分析每个表和索引的工作负载特征。它基于以下两个指标：
U：特定表、索引或分区上的更新操作相对于该对象上的总操作的百分比。U 的值越低（即表、索引或分区不经常更新），它就越适合进行页面压缩。
S：表、索引或分区上的扫描操作相对于该对象上的总操作的百分比。S 的值越高（即表、索引或分区被扫描的次数越多），它就越适合进行页面压缩。
以上两者显然都偏向于推荐 DW 样式数据库（读取密集型/独占性、大数据操作）的页面压缩。
我自己在 1-2 年旧硬件上的实验中仅获得了 2 美分：
我发现页面压缩表（~80 行/页）上的只读操作（DW 样式扫描、排序等）在压缩大小减少约 3 倍时可以实现收支平衡。
即，如果表适合内存，页面压缩只会在数据大小缩小超过 3 倍时提高性能。您在内存中扫描的页面更少，但扫描每一页所需的时间更长。
我想如果您的计划是嵌套循环和大量搜索，您的里程可能会有所不同。其中，这也取决于硬件（外部 NUMA 节点访问惩罚、内存速度等）。
以上只是我遵循的粗略经验法则，基于我自己的测试运行，使用我自己的查询在我自己的硬件（Dell Poweredge 910 及更小机型）上运行。这不是福音啊！
编辑：昨天，Thomas Kejser 出色的 SQLBits XI 演示以视频形式提供。与此讨论非常相关，它显示了页面压缩的 CPU 成本“丑陋”的一面——更新速度减慢了 4 倍，锁定时间更长。
但是，Thomas 正在使用 FusionIO 存储，他选择了一个仅“仅”符合页面压缩条件的表。如果存储在典型的 SAN 上并且使用的数据压缩 3x-4x，那么情况可能就不那么引人注目了。