Question

我有一个包含多个索引的表（定义如下）。无论重建/重新组织索引，其中一个索引（IX_external_guid_3）都有99％的碎片。任何人都知道可能导致这种情况的原因，还是解决问题的最佳方法？

我们正在使用Entity Framework 4.0来查询，其他索引字段上的EF查询平均速度比external_guid_3字段快10倍，但是ADO.Net查询的速度大致相同（尽管比两者慢2倍） EF查询到索引字段。）

表

id（PK，int，not null）
guid（uniqueidentifier，null，rowguid）
external_guid_1（uniqueidentifier，not null）
external_guid_2（uniqueidentifier，null）
state（varchar（32），null）
value（varchar（max），null）
infoset（XML（。），null） - ＆gt;通常2-4K
created_time（datetime，null）
updated_time（datetime，null）
external_guid_3（uniqueidentifier，不是空）
FK_id（FK，int，null）
locking_guid（uniqueidentifer，null）
locked_time（datetime，null）
external_guid_4（唯一标识符， null）
corrected_time（datetime，null）
is_add（位，非空）得分（int， null）
row_version（timestamp，null）

索引

PK_table（群集）
IX_created_time（非唯一，非群集）
IX_external_guid_1（非唯一，非群集）
IX_guid（非唯一，非群集）
IX_external_guid_3（非唯一，非群集）
IX_state（非唯一，非群集）

Answer 1

注意：SQL Server最佳实践表明，少于10,000页的索引通常不会从性能提升中受益。

参见http://technet.microsoft.com/en-gb/library/cc966523.aspx http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx?pr=blog

这里有一个小片段来确定您的数据库何时需要进行碎片整理。在我们的产品中，我们将其减少到2000并选择了> 20％的碎片。您可以轻松修改脚本，特别是告诉您哪些内容。

SELECT COUNT(*) AS fragmented_indexes FROM sys.dm_db_index_physical_stats(DB_ID(), null, null, null, null) as p WHERE p.avg_fragment_size_in_pages <= 1 AND p.avg_fragmentation_in_percent >= 20 AND p.page_count > 2000;

Answer 2

它实际上看起来就像在guid上索引可能是罪魁祸首： http://www.sqlskills.com/blogs/paul/can-guid-cluster-keys-cause-non-clustered-index-fragmentation/

最近我发现了一些似乎支持这一点的参考文献。

Answer 3

您可能在索引中没有足够的数据来进行碎片整理。在你获得了几千行后，重建和重组将摆脱碎片。

在索引页数达到100左右之前，碎片不会影响性能。

您还需要验证索引是否涵盖您的查询以及索引是否正在使用。

从管理工作室运行查询（您可以使用sql profiler或活动监视器捕获查询，如果它是动态的），然后单击“包括实际执行计划”。这将告诉您正在使用的索引以及查询是否被覆盖。

Answer 4

Turn db auto shrink off。它似乎有碎片索引的副作用。

Microsoft SQL Server 2008 - 非群集，非唯一索引上的99％碎片

4 个答案: