インデックスの再構築時間は断片化レベルに依存しますか？
インデックスの再構築に必要な時間は、断片化のレベルに依存しますか？
80％フラグメント化されたインデックスの再構築は、40％フラグメント化された同じインデックスの再構築に1分かかる場合、約2分かかりますか？
特定の状況でどのアクションが必要かについてではなく、必要なアクションを実行するために必要となる可能性があるRUNTIME（秒単位など）を求めています。インデックスの再編成または再構築/統計の更新を行う必要がある場合の基本的なベストプラクティスを知っています。
この質問では、REORGおよびREORGとREBUILDの違いについては尋ねられません。
背景：さまざまなインデックスメンテナンスジョブ（毎晩、週末は重いジョブ...）のセットアップのため、毎日の「非常に激しい」オフラインインデックスメンテナンスジョブは、中程度の断片化されたインデックスでより適切に実行して、オフタイムが小さい-またはそれは問題ではなく、80％フラグメント化されたインデックスでの再構築は、40％フラグメント化された同じインデックスでの同じ操作と同じオフタイムを取る可能性があります。
私は提案に従い、何が起こっているのかを自分で見つけようとしました。私の実験的なセットアップ：他にNOTHINGを実行し、他の誰にも使用されていないテストサーバーで、一意の識別子の主キー列にクラスター化インデックスを含むテーブルを作成し、いくつかの追加の列とさまざまなデータ型[2つの数値、9つの日時、 2 varchar（1000）]と単純に行を追加しました。提示されたテストでは、約305,000行を追加しました。
次に、更新コマンドを使用して、整数値でフィルタリングする行の範囲をランダムに更新し、文字列値を変更してVarChar列の1つを変更し、断片化を作成しました。その後、_avg_fragmentation_in_percent_の現在の_sys.dm_db_index_physical_stats_レベルを確認しました。ベンチマークの「新しい」断片化を作成するたびに、次の図を構成する記録に_physical_page_count_値を含むこの値を追加しました。
次に、私はAlter index ... Rebuild with (online=on);を実行し、_CPU time_を使用して_STATISTICS TIME ON_を録音に取り込みました。
私の期待：私は少なくとも、断片化レベルとCPU時間の間の依存関係を示す一種の線形曲線の兆候を見ることを期待していました。
これはそうではありません。この手順が本当に良い結果に適しているかどうかはわかりません。行/ページの数が少なすぎるのではないですか？
しかし、結果は、私の元の質問に対する答えが間違いなく[〜＃〜] no [〜＃〜]であることを示しています。 SQL Serverがインデックスを再構築するために必要なCPU時間は、断片化レベルにも基になるインデックスのページ数にも依存していないようです。
最初のグラフは、以前の断片化レベルと比較した、インデックスの再構築に必要なCPU時間を示しています。ご覧のように、平均線は比較的一定であり、断片化と必要なCPU時間との間にはまったく関係がありません。
再構築に多少の時間を必要とする可能性がある更新後のインデックス内のページ数の変化の影響を尊重するために、FRAGMENTATION LEVEL * PAGES COUNTを計算し、この値を、必要なCPU時間の関係を示す2番目のグラフで使用しました対断片化とページ数。
ご覧のとおり、これは、ページ数が変わっても、再構築に必要な時間が断片化の影響を受けることを示していません。
これらのステートメントを作成した後、巨大で高度にフラグメント化されたインデックスを再構築するために必要なCPU時間は行の数によってのみ影響を受ける可能性があるため、私の手順は間違っていると思います。私はこの理論を本当に信じていません。
だから、私は本当にこれを絶対に見つけたいので、それ以上のコメントと推奨事項は大歓迎です。
断片化のレベルに応じて、インデックスの再構築に必要な時間はありますか？
これは、SQLサーバーが決定する主要なパラメータではなく、インデックスの再構築/再編成に時間がかかると思います。
「DATA」に基づいて、他のさまざまな要素が関係しており、それを使用して所要時間を決定します。
要因1：テーブルのサイズ
要因2：可用性の懸念
要因3：パーティション化
要素4：インデックス列と一意性
これらの要素の詳細については、 ここ を参照してください。
同じインデックスの40％の再構築に1分かかる場合、80％の断片化されたインデックスの再構築には約2分かかりますか
再び答えは依存することができます！数値については、シナリオをテストし、それがどのように機能するかを確認する必要があります。 FRAGレベル80の場合、再構築にX時間\分\秒かかり、フラグメントレベル40の場合、再構築にY時間\分\秒かかりました。履歴を計算して保持し、15日以上（スケジュールされたメンテナンスアクティビティによって異なります）を言い、両方を比較するのに実際にかかった時間について結論を出すことができます。
さらに：
インデックスの再構築の進行状況に関するデータ\計算を収集できます：
dMV sys.dm_exec_requestsまたは
OlaのRe-indexing-Re-organizingのメンテナンスプランがある場合、メンテナンス中に実行されたアクションの履歴を SQL Serverインデックスと統計のメンテナンス で説明されているようにCommandLogテーブルに保存するオプションがあります。データが保存されると、コマンドタイプ「ALTER_INDEX--REBUILD」と、列の開始時間と終了時間の違いをクエリできます
興味のある方のために、私は、インデックスの断片化とページのサイズに関連して、数週間以内に約2500のインデックス再構築のインデックス再構築期間を示すグラフを作成しました。
このデータは、10個のSQLサーバー、数百のテーブル、および Ola Hallengrenの最適化手順 に基づいています。再構築の一般的なしきい値は5％の断片化に設定されています。
読みやすくするために、この統計で最大のテーブル（10 Mi +ページ）の一部を切り捨てました。
チャートは、泡のサイズとして必要な時間（期間）を示しています。最大のバブルの値は約220秒です。インデックスの再構築に必要な時間は、実際には断片化とは関係がないことを示しています。代わりに、インデックスのページ数により依存しているようです。また、低レベルの断片化は、高レベルの断片化よりも時間がかかることを示しています。 
2番目のグラフは、200 Kページ以下の領域に拡大されています。同じように表示されますが、断片化が増えるのではなく、インデックスが大きいほど時間がかかります。 
インデックスのREBUILDは断片化に依存しません。インデックスを完全に削除し、最初から作成します。
REORGANZE index-インデックスを再構築せずに断片化を減らすため、削除して作成する必要はありません。
MSは、30％以下の断片化にはReorganizeを使用することをお勧めします。より高い断片化には、再構築が推奨されます。
これに関するMSDNの記事は次のとおりです。 インデックスの再編成と再構築
更新
操作の完了にかかる時間に関しては、インデックスの断片化に明らかに依存します。非常に断片化されたインデックスの再構築は、再編成よりも時間がかかりません。わずかに断片化されたインデックスの再構築には、かなり時間がかかります。 MSガイドラインを開始点として、テーブルでいくつかのテストを実行することをお勧めします。断片化％に関する損益分岐点は、特定のテーブル、インデックスのサイズ、およびデータのタイプによって異なります。
同じインデックスを40％フラグメント化した場合の再構築に1分かかる場合、80％にフラグメント化したインデックスの再構築には約2分かかりますか？
REBUILDとREORGのアルゴリズムは異なります。 REORGは、REBUILDとは対照的に、新しいエクステントを割り当てません。 REORGは現在割り当てられているページで動作し（ページを移動できるように1つの8Kbランダムページを割り当てます）、ページを移動し、必要に応じてページの割り当てを解除します。
SQLSkillsの内部（以前はIE0）のメモから....
REBUILDの場合：
- 複数のCPUを使用できます。並列処理を利用して、作業を高速化できます。
- 非常に断片化されたインデックス（例のように80％）の場合、REBUILDはREORGよりもはるかに高速です。 REBUILDはインデックスの別のコピーを作成するだけですが、REORGは断片化の削除に行き詰まるため、速度が低下します。これが Paul Randalが彼の一般的な推奨事項を示した 非常に断片化されたインデックスのREBUILDを実行するのが良い理由です。
- REBUILDを使用すると、リカバリモードをBULK_LOGGEDに変更して、ログ記録を最小限に抑えることができます 生成するログレコードが少ない 。
インデックスREORGの場合：
- 常にシングルスレッドです。並列処理はありません。
- 断片化の激しいインデックスの場合は遅くなり、断片化の軽いインデックスの場合は速くなります。インデックスの作成と、断片化の軽いインデックスの再編成を行う場合のコストは大きくなるため、断片化が軽いインデックスの場合、REORGの方が高速になります。
- REORGは常に完全にログに記録された操作です。
古いスレッドであることは知っていますが、Paul Randalの投稿をここで共有することは有益だと思います。
アルゴリズム速度
断片化がない場合でも、インデックスの再構築は常に新しいインデックスを構築します。再構築にかかる時間は、インデックス内の断片化の量ではなく、インデックスのサイズに関連しています。
https://www.sqlskills.com/blogs/paul/sqlskills-sql101-rebuild-vs-reorganize/
はい。通常、再構築では、行を（順番に）新しい物理インデックスパーティションにストリーミングしながら、元のインデックスを順番にスキャンする必要があります。断片化はキャッシュされていないスキャンに悪影響を与えるため、はい、再構築にはさらに時間がかかります。
どれだけ長くかかるかは、断片化と、CPUがプロセス全体にバインドする方法に依存します。行のシリアル化はCPUをかなり集中的に使用するため、まったく問題にならない場合があります。または、ランダムにIOレートは通常1.5MB /秒であり、これは高速の再構築よりも簡単に5〜10倍遅くなります（スキーマとデータによって異なります）。想定に応じて、おそらく1倍から100倍のスローダウンの間で何でも工夫できます。
同じインデックスを40％フラグメント化した場合の再構築に1分かかる場合、80％にフラグメント化したインデックスの再構築には約2分かかりますか？
それは線形関係ではありません。断片化メトリックは、パーティションのスキャンにかかる時間の大まかなプロキシveryです。