我在SQL 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列上。 当我试图在pipe理工作室重build索引时，它告诉我每个人都“成功”。 但是，当我再次查看碎片时，什么也没有改变。 该表只有2300行。 不知道这是否是相关的，但我也注意到，当我右键单击一个索引，select属性，然后select碎片页面，需要一个长时间（大约30秒）拉起碎片信息。
DB中的其他索引重build没有问题。
任何想法，为什么我不能实际重build这些指数？ 任何想法为什么需要很长的时间来拉碎碎片信息？ 谢谢！
乔恩，
2300行，根据您的模式，每行占用大约118个字节，共计约65页。 在SQL Server中，一个页面大约有8 KB，你可能已经知道这一点。 在这些小桌子里，碎片不是什么大事，你不必担心。
最初空间分配给表作为一个单一的页面分配，一旦它有多达3个范围，那么它将统一的程度。 前几个单页分配激增了碎片信息。 希望这可以帮助。
我已经注意到了碎片选项上的同样的事情，我发现使用DBCC SHOWCONTIG WITH ALL_INDEXES，TABLERESULTS可以一次获取所有表的统计信息，或者只是执行一个表。
我不担心在较小的表上的碎片级别，似乎他们有时不进行碎片整理，不知道它是碎片整理过程中的错误，还是计算碎片级别，但是有几千行，会影响性能。