インデックスの再構築には、再編成よりも多くのCPUが必要です。それは考慮に入れなければならないようにデータベースをロックします。断片化が40％を超える場合は、インデックスを再構築する必要があります。その後、サーバーが再編成するには遅すぎて扱いにくくなります。断片化が約10％から40％になったら、インデックスを再編成する必要があります。したがって、健全なインデックスは基本的に断片化が10％未満で、おそらく10％未満です。
これらは私の経験則であり、私にとってはうまくいきましたが、ガイドラインです。非常に多くのことがパフォーマンスを変化させるため、環境内で何が必要かを調べる必要があります。
今日、少なくともSQL ServerのEnterpriseバージョンを使用している場合はオンラインでインデックスを再構築できると思います。
いくつかの変数があります：-変更されている（挿入/更新された）データの量-データの量-メンテナンスウィンドウがあるかどうか、およびその期間
一般的なコンセンサスは、おそらく週末に週に1回、他のメンテナンス（dbcc checkdbなど）とともに一般的なインデックスの再作成を行うことを検討し、監視/評価することです。
インデックスの断片化の実際的な影響は、データセットのサイズとクエリ方法に大きく関係します。私の具体的ではない答えは、再編成によって十分に速くならない場合に、再編成から再構築に切り替えるというものです。
もう1つの大きな変数は、高度に挿入/更新されたテーブルのインデックスは当然、読み取りが多いテーブルよりもはるかに断片化されるため、パフォーマンスベースラインでそれを考慮する必要があります。 （たとえば、インデックスがすぐに断片化すると予想される場合は、インデックスが元の状態のときにクエリパフォーマンスメトリックを実行しないでください。）
Enterprise Editionでオンラインで再構築を実行することはできますが、完了するまではかなり深刻なパフォーマンスの低下が伴うことに注意してください。データベースのワークロードやクエリ実行時間の増加の影響によっては、価値がない場合があります。