标签: compression

从 Microsoft SQL Server 检索的数据是否被压缩？如果这是由连接字符串控制的，是否有任何简单的方法可以判断是否有任何特定应用程序正在使用它？

我正在检查分析工具，数据量可能需要几分钟才能通过我们的网络传输。我想知道如果我们从同一远程服务器上的压缩数据存储中提取数据，我是否应该期待性能提升。

只要我们讨论这个话题，我就很好奇：数据是用二进制还是 ASCII 传输？例如，如果12345从INT列中查询值，是否将其作为五个字节0x31、0x32、0x33、0x34、0x35传输；该值所需的两个字节；或列所需的四个字节？

需要明确的是，我知道有一些关于压缩存储数据和备份数据的选项。我问的是数据是如何传输的。

我正在尝试压缩一些具有NVARCHAR(MAX)字段的表。不幸的是，压缩row和page压缩没有预期的影响（对于 20 GB 表仅节省了大约 100/200 MB）。此外，我无法应用列存储和列存储归档压缩，因为它们不支持NVARCHAR(MAX)字段压缩。

谁能告诉我这里是否有其他选择？

我也猜测row和page压缩没有效果，因为NVARCHAR(MAX)列的内容是唯一的。

使用页面压缩 ( ALTER INDEX IX1 REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE))重建其 SQL Server 索引后，后续重建（如某些维护脚本超过某个碎片阈值所做的那样）是否需要再次指定数据压缩？否则索引会被有效地解压吗？

在 MySQL InnoDB 中，ROW_FORMAT 的 COMPRESSED、COMPACT 和 DYNAMIC 有什么区别？

彼此之间有什么好处？

以下是Microsoft Docs 中的一段：

在堆重建之前，作为 DML 操作的一部分在堆中分配的新页面不会使用 PAGE 压缩。通过移除和重新应用压缩，或者通过创建和移除聚集索引来重建堆。

我不明白为什么会这样。如果我有一个具有指定压缩设置的堆，为什么不将它应用于属于该表的页面？

谢谢

我有一个超过 500GB 的大型 PostgreSQL 数据库，它太大了。有没有办法将数据库压缩到更易于管理的大小？我曾尝试使用 SquashFS 执行此操作，并且将数据库压缩到 177GB，但是 PostgreSQL 要求数据库具有写入权限并且 Squashed 系统是只读的。更有经验的数据库用户对实现这个目标有什么建议吗？

该数据库保存地球的 GIS 数据，并将在已部署的系统上本地使用。目前它位于 1TB SSD 上，但是，我试图避免仅仅为了容纳大型数据库而插入额外的硬盘驱动器。数据库按预期执行，没有问题，我只是想将其压缩到更易于管理的大小，并避免将其放在单独的驱动器上。

我希望能够详细了解哪些数据库文件包含数据库中各种 HoBT（对齐和非对齐）的分配单元。

在我们开始为每个文件组创建多个数据文件之前，我一直使用的查询（见下文）一直对我有用，我只能弄清楚如何获得与文件组级别一样的细粒度。

select 
    SchemaName = sh.name, 
    TableName = t.name, 
    IndexName = i.name, 
    PartitionNumber = p.partition_number,
    IndexID = i.index_id,
    IndexDataspaceID = i.data_space_id,
    AllocUnitDataspaceID = au.data_space_id,
    PartitionRows = p.rows
from sys.allocation_units au
join sys.partitions p
    on au.container_id = p.partition_id
join sys.indexes i 
    on i.object_id = p.object_id
    and i.index_id = p.index_id
join sys.tables t 
    on p.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
where sh.name != 'sys'
    and au.type = 2
union all 
select 
    sh.name, 
    t.name, 
    i.name, 
    p.partition_number,
    i.index_id,
    i.data_space_id, …

不久前我一直在阅读有关 MySQL 的文件格式 Antelope 和 Barracuda 的信息，我想知道我是否可以从拥有 Barracuda 和 Compression 中受益。

我的服务器目前正在使用 Antelope，因为它是 MySQL 的默认设置。
由于我拥有的大型数据库，我多次遇到内存问题。我的数据库每天都在增加。

似乎压缩正在为一些人带来好处，例如：http :
//www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/

我知道内存和磁盘空间可能会更低，但我不确定我是否理解这一点（引自文章）：
“根据 top 约 5% CPU 负载（从 80-100% 主要等待 I/O）
0.01秒平均主键查找时间（转换前 1-20 秒）"

我认为这两件事不会改善，因为如果数据被压缩，服务器必须解压缩才能再次获得原始数据，那么CPU使用率会增加是否有意义？

这在读/写密集型应用程序中对您有好处吗？你会建议我改用 Barracuda 和 Compression 吗？

你知道梭子鱼的任何问题吗？
以下问题的答案似乎指出了一些问题，但由于它是 2011 年的，我想说它们现在已经修复：https : //serverfault.com/questions/258022/mysql-innodb-how-to-switch -到梭鱼格式

在 Dynamics AX 中有一个缓存机制，可以将表配置为加载到内存中并缓存。此缓存限制为一定数量的 KB，以防止出现内存问题。我正在谈论的设置被调用entiretablecache并在请求单个记录时将整个表加载到内存中。

直到最近，我们依靠一些脚本来验证具有此设置的表的大小，以查看表大小是否高于此限制。

然而，现在，压缩开始发挥作用，诸如sp_spaceused或sys.allocation_units 之类的东西似乎报告了压缩数据实际使用的空间。

显然，应用程序服务器正在处理未压​​缩的数据，因此 SQL Server 中磁盘上的数据大小无关紧要。我需要未压缩数据的实际大小。

我知道sp_estimate_data_compression_savings但正如名字所说，这只是一个估计。
我希望尺寸尽可能正确。

我能想到的唯一方法是一些复杂的动态 SQL 创建与压缩表具有相同结构的未压缩表，将压缩数据插入到影子表中，然后检查影子表的大小。
不用说，这有点乏味，在数百 GB 的数据库上运行需要一段时间。

Powershell 可能是一个选项，但我不想遍历所有表以select *对它们执行 a以检查脚本中的大小，因为这只会淹没缓存并且可能需要很长时间。

简而言之，如果可能的话，我需要一种方法来获取每个表的大小，因为它一旦被解压缩，并且在呈现给应用程序的等式中会出现碎片。我对不同的方法持开放态度，首选 T-SQL，但我不反对 Powershell 或其他创造性方法。

假设应用程序中的缓冲区是数据的大小。bigint 始终是 bigint 的大小，而字符数据类型是每个字符 2 个字节（unicode）。BLOB 数据也占用数据的大小，枚举基本上是一个整数，数字数据是 numeric(38,12)，datetime 是日期时间的大小。此外，没有NULL值，它们要么存储为空字符串，要么存储1900-01-01为零。

没有关于如何实现的文档，但这些假设基于一些测试以及 PFE 和支持团队使用的脚本（显然也忽略了压缩，因为检查是在应用程序中构建的，而应用程序无法分辨）如果底层数据被压缩），它还检查表大小。例如，此链接指出：

避免对大型表使用 EntireTable 缓存（在 AX 2009 中超过 128 KB 或 16 页，在 AX 2012 中超过“整个表缓存大小”应用程序设置[默认值：32KB 或 4 页]）——改为使用记录缓存。

我读过的一些关于 SQL Server 数据压缩的文献指出，写入成本增加到通常所需的四倍左右。这似乎也暗示这是数据压缩的主要缺点，强烈暗示对于只读存档数据库，性能将（除了少数例外）通过使用 100% 填充页面的数据压缩来提高。

1. 以上说法是否属实？

2. 数据压缩和其他方式之间的主要“变化”是什么（用于阅读）

   • “CPU + x%”？
   • “IO -y%”？
   • 页面拆分发生？
   • tempdb 用法？
   • 内存使用情况？
3. 和写作？

出于此问题的目的，您可以将上下文限制为大型(> 1TB)数据库的PAGE 级压缩，但始终欢迎其他评论。

参考：

SQL Server 存储引擎博客（DW 场景显示压缩非常有利）
数据压缩：策略、容量规划和最佳实践

决定压缩内容的更详细方法涉及分析每个表和索引的工作负载特征。它基于以下两个指标：

U：特定表、索引或分区上的更新操作相对于该对象上的总操作的百分比。U 的值越低（即表、索引或分区不经常更新），它就越适合进行页面压缩。
S：表、索引或分区上的扫描操作相对于该对象上的总操作的百分比。S 的值越高（即表、索引或分区被扫描的次数越多），它就越适合进行页面压缩。

以上两者显然都偏向于推荐 DW 样式数据库（读取密集型/独占性、大数据操作）的页面压缩。