1

我现在明白聚集索引包含所有行数据，而不仅仅是索引字段。我试图了解这对碎片化的影响。

假设我们有一个这样的表：

create table Files
(
    ID uniqueidentifier not null,
    Field1 nvarchar(300) null,
    Field2 nvarchar(300) null,
    Field3 nvarchar(300) null,
    Binary varbinary(max) null
)

现在假设所有这些行都充满了数据，然后在聚集索引中的一些较早的行上，您突然将 Field1、Field2、Field3 和 Binary 设置为空。

正如我以我相当幼稚的方式认为的那样，这其中的一个含义是，清除所有这些值会产生差距，索引会变得支离破碎。我猜这些行的顺序仍然正确，那真的是索引碎片吗？

或者你可以换个角度想；如果它们一开始都是空的并且您插入数据，那么您最终是否不得不将数据洗牌到不同的页面并获得索引碎片？

此外，我知道 LOB 数据存储在单独的分配单元中，尽管我不确定这意味着什么；这是否意味着将 Binary 设置为 null （或填充它）应该对聚集索引碎片没有影响？

4

1 回答 1

1

正如我以我相当幼稚的方式认为的那样，这其中的一个含义是，清除所有这些值会产生差距，索引会变得支离破碎。我猜这些行的顺序仍然正确，那真的是索引碎片吗？

是的。你会得到内部碎片。SQL Server 不会自动压缩数据页以回收空​​间。您可以使用SQL Internals Viewer工具查看此内容。尽管取决于您的工作量，但这不一定是坏事。一定程度的内部碎片可用于缓解以下问题（甚至通过使用 FillFactor 故意添加）

或者你可以换个角度想；如果它们一开始都是空的并且您插入数据，那么您最终是否不得不将数据洗牌到不同的页面并获得索引碎片？

是的。假设页面上没有足够的空白空间来容纳较长的行，您将获得页面拆分以为新数据腾出空间。逻辑顺序将与物理顺序不同，您会得到外部碎片。

于 2010-09-27T09:22:22.133 回答