回答:
どのメトリックを見るべきかについては多くの意見の相違があるので、これにはいくつかの興味深い答えがあると確信しています。私はDBCC INDEXDEFRAG、SHOWCONTIGを作成し、2005年の代わりを設計し、Books Onlineのコンテンツを作成したので、私の見解を示し、Books Onlineの数値と、選択した2005年の保守計画ウィザードについて説明します。
1）（2005）パーセント単位の平均フラグメント化/（2000）論理スキャンフラグメント化2）（2005）平均ページ密度/（2000）ページあたりの平均空きバイト
これらは、クラスター化インデックスと非クラスター化インデックスに等しく適用されます。
1は、論理的な断片化の程度を測定しています。これは、インデックスのリーフレベルでのページの論理的な順序が物理的な順序と一致しない場合です。これにより、範囲スキャン中にストレージエンジンが効率的な先読みを実行できなくなります。したがって、＃1はシングルトンルックアップのパフォーマンスではなく、範囲スキャンのパフォーマンスに影響します。
2は、インデックスのリーフレベルで各ページにある無駄なスペースの量を測定しています。無駄なスペースとは、レコードを保存するためにより多くのページを使用していることを意味します。つまり、インデックスを保存するためのより多くのディスクスペース、インデックスを読み取るためのより多くのIO、およびバッファープール内のメモリにページを保持するためのより多くのメモリを意味します。
しきい値？私の一般的な経験則は、断片化が10％未満であり、何もしません。10〜30％、ALTER INDEX ... REORGANIZE（2005）/ DBCC INDEXDEFRAG（2000）を実行します。30％以上、ALTER INDEX ... REBUILD（2005）/ DBCC DBREINDEX（2000）を実行します。これらは、完全な一般化とのための閾値であるあなたが異なります。
しきい値を見つけるには、断片化レベルに対するワークロードのパフォーマンスを追跡し、パフォーマンスの低下が大きすぎる時期を判断します。その時点で、フラグメンテーションに対処する必要があります。断片化して生きることと、それを取り除くというリソースヒットを取ることの間には、バランスの取れた行為があります。
私はここで、断片化を削除する2つの方法のトレードオフについて触れていません。FILLFACTOR/ PADINDEXのように、断片化を緩和してデフラグを少なくしようとすること、スキーマ/アクセスパターンを変更して断片化を緩和すること、またはさまざまな種類のメンテナンスプラン。
ああ、ところで、私は常に、1000ページ未満のインデックスの断片化を気にしないことをお勧めします。これは、インデックスがおそらくメモリに常駐しているためです（そして、人々が数値を要求したため、私は数値を考えなければなりませんでした）。
これについて詳しくは、データベースのメンテナンスに関するTechNet Magazineの記事（http://technet.microsoft.com/en-us/magazine/cc671165.aspx）を参照してください。http://technet.microsoft.com/en-us/library/cc966523.aspx、およびブログのhttp://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspxの Fragmentationカテゴリにあります。
私はこれについてはちょっと答えすぎだと思いますが、これは私のホットボタンの1つです。お役に立てれば ：-）