为什么我不能重建一些Server索引？

Question

我的Server 2005数据库中有一个表，其中有两个索引严重分散(分别为33.3%和85.7%)。该表如下所示：

CREATE TABLE [dbo].[Seasons](
   [SeasonID] [bigint] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
   [TeamID] [bigint] NOT NULL,
   [Year] [smallint] NOT NULL,
   [Name] [nvarchar](50) NOT NULL,
CONSTRAINT [PK_Seasons] PRIMARY KEY CLUSTERED 
( [SeasonID] ASC )

另一个索引位于TeamID列上。当我试图在管理工作室重建索引时，它告诉我每个索引都是“成功的”。但是，当我再次看到碎片的时候，一切都没有改变。表中只有2300行。不确定这是否相关，但我也注意到，当我右键单击一个索引，选择属性，然后选择碎片页时，需要很长时间(大约30秒)才能提取碎片信息。

数据库中的其他索引重建没有问题。

你知道我为什么不能重建这些指数吗？你知道为什么要花很长时间才能找到碎片化信息吗？谢谢!

Answer 1

琼恩,

2300行，根据您的架构，每一行约占118个字节，总共约65页。在Server中，页面大约是8KB，您可能已经知道这一点了。在这些小表中，碎片不是什么大问题，您不必担心它们。

最初，空间是作为单个页面分配分配给表的，一旦它有多达3个区段，那么它就会有一个统一的范围。最初的几个页面分配会增加碎片信息。希望这能有所帮助。

Answer 2

我注意到了碎片选项上的相同情况，我发现使用DBCC与ALL_INDEXES、TABLERESULTS同时获取所有表的统计信息更容易，或者只需执行一个表。

我也不会担心较小的表上的碎片级别，似乎它们有时不会碎片整理，不确定这是碎片整理过程中的错误，还是碎片级别的计算，但是对于几千行，它不会影响性能。