私の回答ではあまりにも一般的すぎるリスクを冒して、インデックスのメンテナンスプロセスを定期的に実行する必要があると言います。ただし、インデックスのメンテナンスプロセスでは、特にそれを必要とするインデックスのみを再構築/再編成する必要があります。
これは質問を提示します：インデックスはいつ再構築または再編成される必要があるのですか？ローランドはこれについてうまく触れました。繰り返しますが、私は非常に幅広いリスクを冒しています。断片化レベルがパフォーマンスに悪影響を与える場合、インデックスのメンテナンスが必要です。このレベルの断片化は、インデックスのサイズと構成に基づいて変化する可能性があります。
SQL Serverについて言えば、インデックスのサイズとインデックスの断片化レベルを選択する傾向があり、その時点でインデックスのメンテナンスを開始します。インデックスに含まれるページが100ページ未満の場合、メンテナンスは行いません。
インデックスが10％から30％の間で断片化されている場合は、インデックスをREORGANIZEし、統計をUPDATEします。インデックスが30％以上断片化されている場合は、REBUILDによって処理されるため、_UPDATE STATISTICS_を使用せずに、インデックスをREBUILDします。ただし、再構築ではインデックスに直接関連付けられている統計オブジェクトのみが更新されることに注意してください。他の列統計は個別に維持する必要があります。
この答えは、実際に言うには長い道のりです。はい、定期的なインデックスメンテナンスを行う必要がありますが、それを必要とするインデックスに対してのみ行う必要があります。
リレーショナルデータベース（SQL Serverなど）のインデックスをいつ再構築する必要がありますか？
特別なイベントによって高度に断片化された場合は、インデックスを再構築する必要があります。たとえば、インデックス付きテーブルへのデータの大規模な一括読み込みを実行します。
定期的にインデックスを再構築するケースはありますか？
では、定期的なアクティビティが原因で、インデックスが定期的に断片化されている場合はどうでしょうか。定期的な再構築をスケジュールする必要がありますか？どのくらいの頻度で実行する必要がありますか？
Tom Kyte 、この中で クラシックAsk Tomスレッド は以下を推奨します：
インデックスの再構築の間のタイムラグは、おおよそです。
...
それをよりよく言う方法がわからない-インデックスは、余分なスペースを備えた大きくて太いものになりたがっています。これは、更新する列にあります。つまり、インデックスエントリをインデックス内の場所から場所に移動します。ある日、行のコードは「A」、翌日は「G」、「Z」、「H」のようになります。したがって、行のインデックスエントリは、インデックス内の場所を移動します。そのため、スペースが必要です。スペースがない場合は、ブロックを2つに分割してスペースを確保します。現在、インデックスは太っています。時間の経過とともに、インデックスは開始時のサイズの2〜3倍になり、「半分以上空」になりますが、行を移動するので問題ありません。行を移動するとき、部屋を作るためにブロックを分割する必要がなくなりました-部屋はすでに利用可能です。
次に、インデックスを再構築または削除して再作成します（同じ効果があります-再構築が「より安全」です-インデックスを失う可能性がなく、インデックスを再構築できるため、より高速にできますテーブルをスキャンして新しいインデックスをソートおよび構築する代わりに、既存のインデックスをスキャンします）。これで、ニースのスペースはすべてなくなりました。私たちはブロックをもう一度分割するプロセスを開始します-開始したところに戻ってください。
スペースを節約できませんでした。
インデックスは元の状態に戻っています。
あなたはただそれを再構築するためにあなたの時間を無駄にして、この悪循環を繰り返すことになるでしょう。
ここでのロジックは適切ですが、読み取りが多い負荷プロファイルに対して偏っています。
「ファット」なインデックス（つまり、ギャップが多いインデックス）は、実際に新しい行と移動された行のための十分なスペースを確保し、ページ分割を減らし、書き込みを高速に保ちます。ただし、そのファットインデックスから読み取る場合は、より多くのページを読み取って同じデータを取得する必要があります。これは、より多くの空のスペースをふるいにかけるためです。これにより、読み取りが遅くなります。
したがって、読み取りが多いデータベースでは、インデックスを定期的に再構築または再編成する必要があります。 （どのくらいの頻度で、どのような条件下で？Matt Mはすでにこの質問に対して 具体的な答え を持っています。）ほぼ同等の読み取りおよび書き込みアクティビティが発生するデータベース、または書き込みが多いデータベースでは、定期的にインデックスを再構築することにより、データベースのパフォーマンスを低下させます。
ほとんどの人は定期的に再構築するため、断片化することはありません。それらを再構築する必要がある場合は、断片化の速度に基づいています。一部のインデックスは頻繁に再構築する必要がありますが、他のインデックスは基本的に再構築する必要はありません。 script the SQLFool を確認して、このことを理解するための多くの処理を行ってください。
Matt Mの承認された回答で述べられているように、一般的な経験則では、30％を超える断片化されたインデックスを再構築する必要があります。
このクエリは、30％以上フラグメント化されているインデックスの数を見つけるのに役立ちます（インデックスがある場合は、再構築する必要があります）。
SELECT DB_NAME() AS DBName,
OBJECT_NAME(ind.object_id) AS TableName,
ind.name AS IndexName,
indexstats.index_type_desc AS IndexType,
indexstats.avg_fragmentation_in_percent,
indexstats.fragment_count,
indexstats.avg_fragment_size_in_pages,
SUM(p.rows) AS Rows
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.indexes AS ind ON ( ind.object_id = indexstats.object_id
AND ind.index_id = indexstats.index_id)
INNER JOIN sys.partitions AS p ON ( ind.object_id = p.object_id
AND ind.index_id = p.index_id)
WHERE indexstats.avg_fragmentation_in_percent > 30
GROUP BY
OBJECT_NAME(ind.object_id),
ind.name,
indexstats.index_type_desc,
indexstats.avg_fragmentation_in_percent,
indexstats.fragment_count,
indexstats.avg_fragment_size_in_pages
ORDER BY indexstats.avg_fragmentation_in_percent DESC
いつインデックスを再構築する必要がありますか？
インデックスの断片化の割合が30％を超える場合。
定期的にインデックスを再構築するケースはありますか？
そのようなケースはありませんが、一般的には、週に1回、週末にインデックスメンテナンスを行うことが、環境を安定させるためのベストプラクティスです。
Ola Hallengrenのメンテナンススクリプト（最高のメンテナンススクリプト）を使用し、環境に基づいてスクリプトをカスタマイズし、週末に実行するようにスケジュールすることをお勧めします。
注：インデックスを再構築してもすべての統計が更新されるわけではないので、インデックスを再構築した後に統計を更新することを忘れないでください。
ITのほとんどのことと同様に、状況によって異なります。インデックスを再構築して修正しようとしている問題は何ですか？それが実際に問題を修正していることを示すことができますか？その場合は、問題を修正するために必要なメンテナンスが最小限になるまで、数値を微調整します。
それでも問題が解決しない場合、またはそれを実行している理由が、状況を改善する可能性があるために監視するいくつかのメトリックを緩和するためである場合、実行しているのはCPUを燃焼し、IO =そして問題を悪化させる可能性があります。
断片化を修正してもサーバーに影響はないという議論があるので、定期的に実行する価値はありますか？
https://www.brentozar.com/archive/2017/12/index-maintenance-madness/