sql - SQL Server 2005 索引碎片

Question

我继承的 SQL Server 2005 数据库中的几个键具有非常高的碎片百分比。使用以下 SQL 时：

select  OBJECT_NAME(object_id), avg_fragmentation_in_percent, record_count, *
from    sys.dm_db_index_physical_stats (DB_ID(N'FragmentedDB'), NULL, NULL, NULL, 'Detailed') s

我看到几个表的碎片百分比在 50 到 99 之间。这些表都有超过 100,000 行，有些有 2,000,000+。我相信这会导致我们的应用程序出现严重的性能问题，因此我尝试使用以下 sql 重建其中一些索引：

ALTER INDEX ALL ON [dbo].[FragmentedTable] 
REBUILD WITH ( FILLFACTOR = 90, ONLINE = ON )

但是，在我重建索引并再次查看碎片百分比后，它们都没有改变。有什么我想念的吗？我已经对这个主题进行了一些搜索，但到目前为止都是空的。

谢谢！

Answer 1

您将“详细”与 dm_db_index_physical_stats 一起使用。这将显示索引的非叶级别以及叶级别。

是叶级别的碎片（leaf_level = 0），非叶级别（leaf_level > 0），还是两者兼而有之？

如果碎片在非叶子级别，这不是问题，或者没有问题。

如果您仍想摆脱所有碎片，请尝试添加 PAD_INDEX。

Answer 2

有两种去除碎片的方法。这两种方法是必要的，因为它们具有完全不同的特性。

描述 SQL Server 2005 及以后的三种方法之间的区别：

ALTER INDEX … REORGANIZE（新的 DBCC INDEXDEFRAG）

ALTER INDEX … REBUILD（新的 DBCC DBREINDEX）

改变索引……重建

更多信息
http://sqlnetcode.blogspot.com/2011/11/sql-server-methods-for-removing.html

Answer 3

我想到了几件事——首先是如果您使用多个文件来支持表中的索引，接下来是您在重建索引时看到的并行性。接下来，您提到您认为这会导致性能问题，您是否验证过这种情况？即除了一些例外，碎片通常是扫描与搜索的更大问题。有关碎片的完整详细回顾，如何解决，集中在哪里，以及您在不同修复方法中看到的差异，请参阅本系列博客文章。

Answer 4

想法..

• 是分区的吗？REBUILD PARTITION = partition_number
• 需要LOB_COMPACTION = ON吗？
• 你有聚集索引吗？