表中带有 VARBINARY(MAX) 列的 IDENTITY 列上的 PK 索引碎片答案

【问题标题】：PK Index fragmentation on IDENTITY columns with VARBINARY(MAX) column in table表中带有 VARBINARY(MAX) 列的 IDENTITY 列上的 PK 索引碎片
【发布时间】：2015-11-06 19:13:55
【问题描述】：

我有一些表（表 A 和表 B），其 BIGINT 以 IDENTITY 规范作为主键。在这些表中，我有 2 个 VARBINARY(MAX) 列。更新和删除非常罕见。

它们的行数几乎相同，表 B 少一点，但 VARBINARY(MAX) 列中的数据要多得多。

我惊讶地发现，表 B 中 PK 使用的存储量远高于表 A 中 PK 使用的存储量。做一些阅读，如果我错了，请纠正我，澄清这与大约 8k 的最大行大小有关。因此，存在一些使用字节引用进行的分页，然后将其包含在索引中。因此，表 B 中 PK 使用的存储空间更大。它大约是数据库总大小的 30%。我假设只有 BIGINT 是索引的一部分。

我的问题是是否有解决方法？有什么设计、技术或黑客可以防止这种情况发生吗？

问候

维尔玛

【问题讨论】：

标签： sql-server primary-key varbinarymax large-data

【解决方案1】：

PK 是一个集群索引：数据与密钥一起存储。每个表只能有一个聚集索引，因为数据只能存储在一个地方。因此任何聚集索引（例如 PK）都会比非聚集索引占用更多空间。

如果 B 中有更多的 varbinary 表，那么我希望 PK 占用更多空间。

但是，由于这个 varbinary 是 (MAX)，所以最初的想法是只有数据指针应该与密钥一起存储。但是，如果行足够小（即

物有所值！

【讨论】：

我明白了。所以假设本例中的 VARBINARY(MAX) 数据嵌入在 PK 聚集索引中。那它是多余的吗？是否也存储在列中？
我的猜测是在某些情况下（当 varbinary 足够短时）它会与索引一起存储，是的；当它变得足够长以至于不可能时，它就会被分流到存储大东西的地方，并在索引中用指向大东西存储的指针替换。