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 回答