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から：

スキャン密度[ベストカウント：実際のカウント]

パーセンテージです。これは、実際のカウントに対するベストカウントの比率です。すべてが連続している場合、この値は100です。この値が100未満の場合、断片化が存在します。

ベストカウントは、すべてが連続してリンクされている場合のエクステント変更の理想的な数です。実際のカウントは、エクステントの変更の実際の数です。

論理フラグメンテーション

インデックスのリーフページのスキャンから返された順序が正しくないページの割合。この数はヒープには関係ありません。アウトオブオーダーページとは、インデックスに割り当てられた次の物理ページが、現在のリーフページの次のページポインタが指すページではないページです。

ただし、断片化のレベルが高すぎるため、減らす必要があるというガイダンスはありません。また、スキャン密度が低すぎるため、増やす必要があるというガイダンスもありません。

4

1 に答える 1

3

SQL の他のものと同様に、依存します。

競合（「競合」するデータページが増えるため、待機時間が長くなります）、インデックスの幅などに依存します。

個人的な経験から、実行するいくつかのビルドとロードに対する断片化の影響についていくつかのテストを行いました。

集計集約型の手順では、断片化が 40% のテーブルに対して 1 回実行し、断片化が 0% の「同じ」テーブルに対して別の実行を実行しました。

40% 断片化されたテーブルは、同じ基本操作を実行するのに1,200% 長くかかりました。

走行距離は異なる場合がありますが、大きな違いがあります。

おそらく SQL Server 2005+ の DBCC のほとんどを担当している Paul Randal は、これもかなり大きな取引だと考えています。

要するに、確実に知る唯一の方法は、テストを行うことです。「一般的な」評価を行うには変数が多すぎるため、BOL は密度と断片化の範囲に関するガイドラインを示していません。

「私の車はあまりにも損傷していますか？」と尋ねるようなものです。答えは、「何に対して損傷が大きすぎるのか」、走行距離、速度、道路の種類、天候、季節、その他の無数の事柄によって異なります。

于 2011-10-05T19:39:14.757 に答える