web-dev-qa-db-ja.com

SQL Serverでの高インデックスの断片化の原因は何ですか？

SQL Serverデータベースを使用しているアプリケーションがあります。アプリケーションは長年使用されているため、データベースのサイズが非常に大きく、アプリケーションの速度が低下します。データの断片化が高いことがわかりました。したがって、週に2回、インデックスのデフラグと構築を行います。最適化後のデータベースの断片化レポートは次のとおりです。

enter image description here

アプリケーションでもデフラグ後2〜3日間しか使用されない場合でも、結果は依然として高いフラグメンテーションを示しています。結果が正常で満足できるものであるかどうか、専門家に教えてもらえますか？誰かがこの結果の何らかの理由を示唆できますか？

sql-serverindexfragmentation
2
Umair

考慮すべき事項は次のとおりです。

  1. フィルファクター
  2. インデックス/テーブルのソート順。テーブルクラスタインデックスがIDに基づいていない場合。新しいレコードが挿入されているとき、新しいレコードがテーブルの真ん中に入る可能性があります。クラスタインデックスを台無しにします
  3. 更新および削除操作
  4. 最後にインデックスを再構築したとき
1
user41935

上記のように、ページ分割/不正な塗りつぶしのケースである可能性があるため、SQLSkillsには​​、拡張イベントを使用してページ分割を監視し、ページのスパイトを削減する優れた記事があります。>> 問題のあるページ分割の追跡

1
Darren

並列で（またはMAXDOPを指定せずに）インデックスを再構築すると断片化が発生する場合があることを確認しました。

オプションMAXDOP = 1を使用してインデックスを再構築してください。

ALTER INDEX（Transact-SQL）

これにより、再構築ジョブにかかる時間が長くなりますが、断片化を減らすのに役立つ場合があります。 Standard Editionを使用している場合、インデックスは再構築されるまで使用できません。 Enterpriseでは、ONLINE = ONパラメータを指定して影響を軽減できます。

使用頻度の高いデータベースサーバーでこれを確認しました。

1
John aka hot2use

これは、特にこれらのクラスター化インデックスにとって、かなり高い断片化です。これらのID列はGUIDですか？自動インクリメントする数値PKは、そのインデックスのすべてのデータが順番に挿入されているため、実際には断片化されません。 GUIDはランダムであるため、インデックスの断片化の絶対最悪のケースです。

1
Ben Campbell