碎片坏了多少？扫描密度有多低太低？ 扫描密度有多低坏？
我有一个包含以下索引密度和碎片级别的表：
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％的碎片可怕高吗？
我得到performance issues when deleting rows（需要索引扫描）。索引碎片在70000页索引上是 GIANT FLASHING RED ALARM ，还是可能但不太可能？
从SQL Server BOL：
扫描密度[最佳计数：实际计数]
是百分比。它是最佳计数与实际计数的比率。如果一切都是连续的，则该值为100;如果此值小于100，则存在一些碎片。
如果所有内容都是连续链接的，那么最佳计数是范围更改的理想数量。 实际计数是范围更改的实际数量。
LogicalFragmentation
扫描索引的叶子页返回的无序页面的百分比。这个数字与堆数无关。无序页面是分配给索引的下一个物理页面不是当前叶页中下一页指针所指向的页面的页面。
但是没有关于什么级别的碎片太高，并且应该减少的指导。关于什么扫描密度太低也没有任何指导，应该增加。
答案 0 :(得分：3)
与SQL中的任何其他内容一样，取决于。
这将取决于竞争之类的东西（由于有更多数据页面需要“竞争”，因此增加了等待时间），索引的宽度等等等。
根据我的个人经验，我对一些构建和负载的碎片影响进行了一些测试。
对于聚合密集型过程，我针对40％碎片的表运行了一次运行，而另一次针对“0”碎片的“同一”表运行。
40％零碎的表格 1,200％更长来运行相同的基本操作。
您的里程可能会有所不同，但这会产生很大的不同。
简而言之，唯一可以确定的方法是进行测试。 BOL没有给出密度和碎片范围的指导原则，因为有太多变量无法进行“一般”评估。
这就像问“我的车太受损了吗？”答案取决于“太多损坏了什么？”，你驾驶的距离，速度，道路，天气，一年中的什么时间以及其他一百万件事。