2

多少碎片是坏的？扫描密度有多低才算过低？扫描密度有多低是坏的？

我有一个具有以下索引密度和碎片级别的表：

Name                           Scan Density  Logical Fragmentation
=============================  ============  =====================
IX_TransactionEntries_Tran...  12.834        48.392
IX_TransactionEntries_Curr...  15.419        41.239
IX_TransactionEntries_Tran...  12.875        48.372
TransactionEntries17           98.081         0.0049325
TransactionEntries5            12.960        48.180
PK_TransactionEntries          12.869        48.376
TransactionEntries18           12.886        48.480
IX_TranasctionEntries_CDR...   12.799        49.157
IX_TransactionEntries_CDR...   12.969        48.103
IX_TransactionEntries_Tra...   13.181        47.127

您可以看到我刚刚进行了碎片整理TransactionEntries17，这就是为什么它的扫描密度如此之高，而它的碎片如此之低的原因。

但是 12% 的扫描密度是不是太低了？48% 的碎片率高得可怕吗？

删除行（需要索引扫描）时出现性能问题。索引碎片是70000 页索引上的巨大闪烁红色警报，还是可能但不太可能的原因？

从 SQL Server BOL：

扫描密度 [最佳计数：实际计数]

是一个百分比。它是Best Count与Actual Count的比率。如果一切都是连续的，则该值为 100；如果该值小于 100，则存在一些碎片。

如果所有内容都是连续链接的，则最佳计数是范围更改的理想数量。实际计数是范围更改的实际数量。

逻辑碎片

通过扫描索引的叶页返回的乱序页的百分比。这个数字与堆无关。乱序页是指分配给索引的下一个物理页不是当前叶页中的下一页指针所指向的页。

但是没有关于什么水平的碎片太高，应该降低的指导。也没有任何关于什么扫描密度太低的指导，应该增加。

4

1 回答 1

3

就像 SQL 中的任何其他内容一样，它取决于.

这将取决于诸如争用之类的东西（这会增加等待时间，因为有更多的数据页要“争用”）、索引的宽度等等等等。

根据我的个人经验，我对碎片化对我运行的一些构建和负载的影响进行了一些测试。

对于一个聚合密集型过程，我对一个碎片率为 40% 的表运行一次，另一次对碎片率为 0% 的“相同”表运行一次。

40% 碎片化的表需要1,200% 的时间来运行相同的基本操作。

您的里程可能会有所不同，但它会产生很大的不同。

Paul Randal，可以说是 SQL Server 2005+ 中大部分 DBCC 的负责人，他认为这也是一笔巨大的交易。

简而言之，唯一确定的方法就是进行测试。BOL 没有给出密度和碎片范围的指导方针，因为变量太多，无法进行“一般”评估。

这就像在问“我的车是不是太损坏了？” 答案取决于“对什么造成的损坏？”、您驾驶的距离、速度、在什么样的道路上、什么样的天气、一年中的什么时间以及其他一百万件事。

于 2011-10-05T19:39:14.757 回答