回答:
私の答えではあまりにも一般的すぎる危険を冒して、インデックスメンテナンスプロセスを定期的に実行する必要があると言います。ただし、インデックスメンテナンスプロセスでは、特に必要なインデックスのみを再構築/再編成する必要があります。
これは、インデックスをいつ再構築または再編成する必要があるのかという疑問を提示します。ローランドはこれにうまく触れました。繰り返しますが、私は非常に広範になるリスクがあります。断片化レベルがパフォーマンスに悪影響を与える場合、インデックスのメンテナンスが必要です。このレベルの断片化は、インデックスのサイズと構成によって異なる場合があります。
SQL Serverと言えば、インデックスのメンテナンスを実行し始めるインデックスサイズとインデックスの断片化レベルを選択する傾向があります。インデックスに含まれるページが100ページ未満の場合、メンテナンスは行いません。
インデックスが10％〜30％断片化されている場合REORGANIZE、インデックスとUPDATE統計情報を作成します。インデックスが30％を超えて断片化されている場合、インデックスはREBUILD-なしUPDATE STATISTICSで処理されますREBUILD。ただし、再構築では、インデックスに直接関連付けられている統計オブジェクトのみが更新されることに注意してください。他の列の統計は個別に維持する必要があります。
この答えは、実際には長い道のりです。はい、定期的なインデックスメンテナンスを行う必要がありますが、それが必要なインデックスに対してのみです。
リレーショナルデータベース（SQL Serverなど）のインデックスをいつ再構築する必要がありますか？
特別なイベントによって非常に断片化された場合、インデックスを再構築する必要があります。たとえば、インデックス付きテーブルに大量のデータを大量にロードします。
定期的にインデックスを再構築する場合はありますか？
では、定期的なアクティビティのためにインデックスが定期的に断片化されている場合はどうでしょうか？定期的な再構築をスケジュールする必要がありますか？どのくらいの頻度で実行する必要がありますか？
この古典的なAsk TomスレッドのTom Kyteは、次のことを推奨しています。
インデックスの再構築間のタイムラグは、ほぼ永遠に続くはずです。
...
より良い言い方がわからない-インデックスは大きくて太く、余分なスペースが必要です。更新する列にあります-インデックスエントリをインデックス内の場所から場所へ移動します。ある日、行のコードは「A」、翌日、コードは「G」、「Z」、「H」のようになります。そのため、行のインデックスエントリはインデックス内の場所から場所へ移動します。そのように、スペースが必要です。スペースがなければ、ブロックを2つに分割し、スペースを作ります。今、インデックスは太っています。時間の経過とともに、インデックスは開始時のサイズの2〜3倍になり、「半分以上空」になりますが、行を移動するので問題ありません。行を移動すると、ブロックを分割してスペースを空ける必要がなくなりました-ルームはすでに利用可能です。
次に、インデックスを再構築またはドロップして再作成します（同じ効果があります-再構築は「より安全」です-インデックスを失う可能性がなく、インデックスを再構築できるため、より高速になりますテーブルをスキャンして新しいインデックスを並べ替えて作成する代わりに、既存のインデックスをスキャンします）。これで、すてきなスペースはすべてなくなりました。ブロックを再び分割するプロセスを開始します。開始した場所に戻ります。
スペースを節約しませんでした。
インデックスは元の状態に戻りました。
あなたはただそれを再構築するためにあなたの時間を無駄にしているだけで、この悪循環が繰り返されます。
ここのロジックは健全ですが、読み取りが多い負荷プロファイルに対してバイアスがかけられています。
「ファット」インデックス（つまり、多くのギャップがあるインデックス）は、実際に新しい行と移動した行のために十分なスペースを確保するため、ページ分割を減らし、書き込みを高速に保ちます。ただし、そのファットインデックスから読み取る場合は、同じデータを取得するためにさらにページを読み取る必要があります。これは、より多くの空きスペースをふるいにかけているためです。これにより、読み取りが遅くなります。
そのため、読み取りが多いデータベースでは、インデックスを定期的に再構築または再編成する必要があります。（どのくらいの頻度で、どのような条件下ですか？Matt Mはすでにこの質問に具体的な答えを持っています。）ほぼ同等の読み取りおよび書き込みアクティビティが発生するデータベース、または書き込みが多いデータベースでは、インデックスの再構築によってデータベースのパフォーマンスが低下する可能性があります定期的に。
ほとんどの人は、断片化しないように定期的にそれらを再構築します。再構築する必要があるときは、断片化の速さに基づいています。頻繁に再構築する必要があるインデックスもあれば、基本的に再構築しないインデックスもあります。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/