我读过的一些关于 SQL Server 数据压缩的文献指出，写入成本增加到通常所需的四倍左右。这似乎也暗示这是数据压缩的主要缺点，强烈暗示对于只读存档数据库，性能将（除了少数例外）通过使用 100% 填充页面的数据压缩来提高。
数据压缩和其他方式之间的主要“变化”是什么（用于阅读）
出于此问题的目的，您可以将上下文限制为大型(> 1TB)数据库的PAGE 级压缩，但始终欢迎其他评论。
参考：
SQL Server 存储引擎博客（DW 场景显示压缩非常有利）
数据压缩：策略、容量规划和最佳实践
决定压缩内容的更详细方法涉及分析每个表和索引的工作负载特征。它基于以下两个指标：
U：特定表、索引或分区上的更新操作相对于该对象上的总操作的百分比。U 的值越低（即表、索引或分区不经常更新），它就越适合进行页面压缩。
S：表、索引或分区上的扫描操作相对于该对象上的总操作的百分比。S 的值越高（即表、索引或分区被扫描的次数越多），它就越适合进行页面压缩。
以上两者显然都偏向于推荐 DW 样式数据库（读取密集型/独占性、大数据操作）的页面压缩。
我一直在对压缩和存储 SQL Server 备份的不同方法进行一些测试（使用 SQL Server 2008 R2 企业版），我想知道最有效的压缩算法是在 SQL 之外长期存储这些备份内部压缩算法。
我不担心物理存储或磁带驱动器或任何东西，只是试图将我们的 3TB 数据和日志文件变成最小的单个文件。
那么，例如，是 .zip 还是 .7z？或者我的数据库中有太多变量无法准确估计什么是最有效的，而我只需要做一些测试？或者 SQL Server 的内部压缩是我能得到的最好的吗？
我需要在 Postgres 中存储大量文本，主要是命令日志和长时间运行命令的输出，并且需要知道是否有一些设置可以帮助使用 zlib 等工具或其他一些本机空间节省方法透明地压缩数据.
数据主要是只读数据，所以写入不是问题。
我正在尝试确定应用哪个以及何时是应用压缩的合适时间。我发布这个问题是为了从这个社区获得洞察力。我已经阅读了几篇文章，但希望在 DB Administrators 中有一个解决此问题的地方。
我创建了一个包含 650 个 Numeric(19,4) 列的表。当我打开页面压缩时，通过运行
ALTER TABLE fct.MyTable REBUILD WITH (DATA_COMPRESSION = PAGE);
我得到
消息 1975，级别 16，状态 1
索引“PK_Mytable”行长度超过了“8060”字节的最大允许长度。
但是 650 乘以 9 字节仅为 5850 字节，这与规定的 8060 字节的限制相去甚远。
服务器运行的是 Windows 2012 r2 和 SQL Server 2016 SP1 CU2
使用页面压缩时的行开销是多少？
这是一些代码来显示我的意思：
/* test script to demo MSG 1975 */
DECLARE @sql NVARCHAR(max)='', @i INT =0
drop table if exists dbo.mytable;
SET @sql = 'Create table dbo.Mytable (MyTableID bigint not null
identity(1,1) primary key clustered, '
WHILE @i < 593 BEGIN
SET …这是我昨天提出的一个问题的后续问题：我可以批量插入空的页面压缩表并获得完全压缩吗？这个问题的答案（转述自 Randi Vertongen 的优秀回答）是肯定的，但它要求批量插入采用表级锁；否则，大容量插入采用行级锁并仅执行行数据压缩。这就提出了一个问题：之后我如何知道应用了什么压缩？
下面是在理论上页压缩的表中创建行压缩数据的步骤：
1. 创建一个表，DATA_COMPRESSION=PAGE并不使用sp_tableoption打开该表的“批量加载表锁定”选项。
2. 使用 bcp 将平面文件中的数据批量插入到新表中，但不指定-h TABLOCK锁定表的选项。
结果是一个表中的数据在行级别上被压缩（小于未压缩表但大于页压缩表），但检查sys.allocation_units目录表显示数据压缩为页。
问题
在这种情况下，当表的数据分配用于页面压缩时，我该怎么做才能确定该表中的数据是否经过页面压缩？
我很好奇 SQL Server 的缓冲池如何受到压缩数据表的影响。
内存中的数据是像在磁盘上一样被压缩，还是完全解压？
如果数据被压缩存储在缓冲池中，那么在执行语句时，给定时间内存中保存了多少瞬时解压数据；一行/页、整个表（假设有足够的空闲页来保存数据），还是“视情况而定”？
我计划对我的数据库（数据仓库）中的一些大表应用 PAGE 压缩。这些表相当大，有超过 150 亿行。
当我在测试环境中应用压缩时，整个过程大约需要 22 个小时。这些表每天都会通过运行很长时间的查询进行访问。
可以在表上设置数据压缩：
CREATE TABLE dbo.SomeTable(
SomeId [bigint] NOT NULL,
OtherId [bigint] NOT NULL,
IsActive [bit] NOT NULL,
CONSTRAINT [PK_Some] PRIMARY KEY CLUSTERED
(
SomeId Desc
)
) ON SomePartitionScheme(SomeId) WITH (DATA_COMPRESSION=PAGE)
它可以在主键上定义：
CREATE TABLE dbo.SomeTable(
SomeId [bigint] NOT NULL,
OtherId [bigint] NOT NULL,
IsActive [bit] NOT NULL,
CONSTRAINT [PK_Some] PRIMARY KEY CLUSTERED
(
SomeId Desc
) WITH (DATA_COMPRESSION=PAGE)
) ON SomePartitionScheme(SomeId)
但是如果你把它放在两者上，你就会得到这个错误：
DATA_COMPRESSION 选项为表指定了多次，如果表已分区，则至少为其中一个分区指定。
把它放在PK上和放在桌子上有什么区别吗？
我正在阅读有关使用 PostgreSQL 进行网络压缩的内容，以查看是否有任何东西可以提供允许大结果集通过网络传输到远程 Web 服务器的内容。似乎没有这种东西。有没有解决方案可以做到这一点，这不是 SSL？
似乎有一个涉及 SSL 的解决方案。阅读了与此相关的线程后，似乎该解决方案不再可取，因为它使系统容易受到CRIME worldwide错误的影响。
尽管不可取，但您似乎至少可以在当前重新启用 SSL 压缩，OPENSSL_DEFAULT_ZLIB但将来它将被删除，并且当前在 openssl 中的编译时被禁用。
no-zlib [default]
no-zlib-dynamic [default]