☰

为什么我无法重建某些 SQL Server 索引？

tag-icon • tag-icon sql-server sql-server-2005 fragmentation
为什么我无法重建某些 SQL Server 索引？

我的 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 列上。当我尝试在 Management Studio 中重建索引时，它告诉我每个索引都“成功”。但是，当我再次查看碎片时，什么都没有改变。该表中只有 2300 行。不确定这是否相关，但我还注意到，当我右键单击索引、选择属性，然后选择“碎片”页面时，需要很长时间（大约 30 秒）才能提取碎片信息。

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

知道为什么我不能实际上重建这些索引？知道为什么提取碎片信息要花这么长时间吗？谢谢！

答案1

乔恩，

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

最初，空间以单页分配的形式分配给表，一旦它有多达 3 个区，它就会成为一个统一区。前几个单页分配会导致碎片信息激增。希望这能有所帮助。

答案2

我在碎片选项上注意到了同样的事情，我发现使用 DBCC SHOWCONTIG WITH ALL_INDEXES, TABLERESULTS 一次获取所有表的统计信息或只获取一个表更容易。

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

相关内容