如果我在表的聚集索引上设置压缩（页或行），这与在表上设置压缩相同吗？
SQL Server 为两者提供了选项，这表明它们是不同的，但我的印象是聚簇索引和表本质上是同一件事，我对聚簇索引如何工作的心理模型告诉我压缩聚簇索引还必须压缩表。
我正在阅读有关使用 PostgreSQL 进行网络压缩的内容，以查看是否有任何东西可以提供允许大结果集通过网络传输到远程 Web 服务器的内容。似乎没有这种东西。有没有解决方案可以做到这一点，这不是 SSL？
似乎有一个涉及 SSL 的解决方案。阅读了与此相关的线程后，似乎该解决方案不再可取，因为它使系统容易受到CRIME worldwide错误的影响。
尽管不可取，但您似乎至少可以在当前重新启用 SSL 压缩，OPENSSL_DEFAULT_ZLIB但将来它将被删除，并且当前在 openssl 中的编译时被禁用。
no-zlib [default]
no-zlib-dynamic [default]
我们有两台服务器。我们刚刚压缩了一个，但我接手了这个小项目，这个人说有些表不是很好的候选人。与许多其他人一样，性能至关重要。说某些表不应该被压缩是否准确？如果是这样，寻找的一般阈值是多少？我运行他的脚本来检查读取/写入的每个对象，但是由于这看起来像是历史，而不是时间范围内发生的事情，因此这可能不是衡量它的准确方法。
我工作的公司有几个 SQL Server 数据库，其中的表包含 +- 500.000.000 行。我们正在运行 SQL Server 2008R2 和 2014 的企业版。
大数据类型
当我查看最大表中使用的数据类型时，我看到很多 BIGINT 列。使用Thomas Larock的脚本检查这些列中的数据并自己编写 MIN() 和 MAX() 值的脚本，我得出结论，这些 BIGINT 列中的数据可以很容易地装入 INT 甚至 SMALLINT/TINYINT 列中。（我知道有些列将来可能需要 BIGINT 的范围，所以我不会在没有先与开发人员交谈的情况下盲目更改所有数据类型）
在比较更改数据类型时可能的节省时，表似乎可能是当前大小的一半（甚至不考虑索引和其他表）。这些数字没有任何数据压缩。
行压缩
在大表上启用了 ROW 压缩。我想知道“缩小”列数据类型的实际影响可能是什么，请记住 ROW 压缩仅使用所需的字节。例如，如果一个值可以存储在 1 个字节中，则存储将只占用 1 个字节。
实际问题
是否有助于缩小数据类型，以便 ROW 压缩使用更少的资源？或者说“因为启用了 ROW 压缩，BIGINT、INT 或 SMALLINT 数据类型之间没有区别”是否可以保存？
创建备份时，SQL Server 会猜测（？）初始备份文件的大小。稍后，也许当它附加日志时，大小会被重新调整，有时会多次调整，直到达到最终大小。差异越大，备份所需的时间就越长。（与另一个备份相比，稍后不会调整大小）。示例：Database1（大小为 500GB，使用了 70GB 的日志）通过压缩进行备份。创建的 .bak 文件大小为 85 GB，一段时间后 CPU 使用率上升，我可以看到 .bak 文件重新调整为 136 GB，这种情况再次发生，直到备份的最终大小为 178GB到达。
当这些重新计算发生时，与同一台机器上的其他备份相比，以 MB/s 为单位的平均备份速度会降低。唯一来自附加和清除日志吗？还是因为数据库中使用的数据类型不同？意味着它们以不同的压缩率压缩，或者其他什么？
我来到这个话题，因为我知道我的备份需要大约 30 分钟，但现在即使数据库没有增长到其大小的 300%，也需要 1.5 小时。它仅增长了 30%。
使用等待统计数据，我可以看到除了 BackupIO 之外，我还在某个时候等待 CPU (SOS_SCHEDULER_YIELD)。
Machine Details:
VMWare 6.0
32 GB of Memory (Max memory 28GB given to SQL Server)
2 logical CPU
Max Degree of Parallelism (1, it's a Sharepoint 2013)
SQL Server 2014
Windows Server 2012 R2
running on an SSD Raid (5)
当然，我为运行备份的用户启用了即时文件初始化。
我有很多大表（大约 1000 万行宽）需要定期加载到 SQL Server 2016 中以进行只读报告。我希望这些表在磁盘上尽可能小，这比加载或查询的性能改进更重要。
这是我对不需要进一步索引的表所做的工作：
DATA_COMPRESSION=PAGE. 表中的列类型是 varchar（不超过 512，不是最大值）、float、tinyint 或日期（不是日期时间）。所有列都创建为可为空的，并且没有定义主键或外键——它们与查询无关，表永远不会直接更新。一切的默认排序规则是SQL_Latin1_General_CP1_CI_AS.
当我这样做时，我可以看到sys.allocation_units该页面数据压缩已应用于堆，并且我可以看到sys.partitions填充因子正确为 0 (100%)。由于表比未压缩的表小得多，我认为压缩已完成。
但是，如果我然后使用相同的选项重建DATA_COMPRESSION=PAGE，则假定已经压缩的表会缩小大约 30%！看起来它从每个数据页大约 17 行到每页 25 行。（虽然只有一次。在那之后再次重建不会使它比第一次重建更小。）
问题
所以我的问题是：（a）这里发生了什么？(b) 有没有办法在加载表时直接获得这个超小的压缩大小，而无需在加载数据后重建？
正在optimize table对我的一个大约 11Gig 大小的表运行命令时，令人惊讶的是，在优化过程完成后，使用的磁盘空间立即增加了 2Gig。我希望优化能够回收空间。
发生了什么？
优化完成后，MySQL CPU 利用率比以前高 2-3 倍，在 24 核机器上平均负载为 18-20。几个小时后，CPU 和平均负载略有下降，但仍高于平时。有没有类似经历的？谢谢。
我创建了一个简单的 CLR 函数来压缩/解压缩NVARCHAR列：
[SqlFunction(DataAccess = DataAccessKind.None, IsDeterministic = true)]
public static SqlBinary Compress( string str ){
if( str == null ){return new SqlBinary();}
if( String.IsNullOrEmpty( str ) ){str = " ";}
byte[] bytes = Encoding.Unicode.GetBytes( str );
using( MemoryStream msi = new MemoryStream( bytes ) ){
using( MemoryStream mso = new MemoryStream() ){
using( GZipStream gs = new GZipStream( mso, CompressionMode.Compress ) ){
msi.CopyTo( gs );
}
return new SqlBinary( mso.ToArray() );
}
}
}
我得到的压缩率大约是 4，或者如果我有 1024 …
我面临着与不断增长的日志文件相关的问题，因此我收到了错误。当我检查 SQL 日志时，我发现以下消息（错误日志中几乎 90% 都填充了这些消息）
SQL Server 遇到 1 次 I/O 请求需要超过 15 秒才能在文件中完成
几乎所有数据库都会发生这种情况，包括 temdb [.mdf 和 .ndf 文件] 以及我也收到以下消息
平均吞吐量：0.34 MB/秒 I/O 饱和度：196 次上下文切换 1210
最后一个未完成的目标：530 avgWriteLatency 2
FlushCache：在 142370 毫秒内清理了 6233 个 buf，384 次写入（避免了 99 个新的脏 buf），用于 db 6:0
我的 temdb 大小和其他数据库和日志文件大小足够大。
历史：
我的行动计划：
我发现日志文件的初始大小很小，增长了 10%。我计划将初始大小增加 512 MB，增加 512 MB 以获得合理数量的 VLF。
问题 1：虽然我会在非高峰时段进行工作，但进行这些更改是否有可能损坏我的数据库或日志文件？
问题二：数据库压缩方式会影响IO操作吗？如果是，我该如何解决？
我计划从防病毒检查中删除所有数据库和日志文件。
我计划将目标恢复时间更改为 < 1 分钟的数据库（特别是 tempdb 和我的数据库）
问题 3：这会影响我的数据库吗？我的意思是刷新缓冲区和写入磁盘应该可以提高性能，对吗？
问题 4：我有 3 个 tempdb …
是否可以在从维护计划调用的存储过程中将备份文件压缩为 .zip（或其他）？
我的维护计划包含以下步骤：
检查数据库（一致性，re_index，也许不重要）
完整备份
使用 restore_verifyonly 检查备份文件
收缩数据库
在 restore_verifyonly/shrink 数据库之后我想压缩这个文件。
compression ×10
sql-server ×6
backup ×2
bcp ×1
datatypes ×1
mysql ×1
network ×1
optimization ×1
performance ×1
postgresql ×1
sql-clr ×1
tempdb ×1
tokudb ×1