インデックスの再構築により、再構築の完了後にパフォーマンスが低下する可能性はありますか？
非常に断片化されている顧客データベースがあります。実際には、1000ページを超えるすべてのテーブルの断片化が95％を超えています。 FILL FACTORは適切な値に設定されていますが、ほとんどのテーブルでは、ページスペースの使用量はFILL FACTORに近くありません。
これは、データベースでメンテナンスが行われていないためです。
Ola HallengrenのIndexOptimize を使用してインデックスを再構築すると、期待どおりに断片化が減少します。既存の製品ハードウェアでは、アプリケーションのパフォーマンスが期待どおりに向上します。私が通常使用するすべてのメトリック-重いクエリのクライアント統計、プロファイラー期間、読み取り/書き込みストール、アプリケーションログ、およびユーザーの知覚-は、パフォーマンスが向上していることを示しています。
ただし、Intel PCIe SSDを搭載した新しいデータベースサーバーは、予想とは逆の結果を示しています。非常に断片化されているため、アプリケーションのパフォーマンスは良好です。インデックスを再構築した後、アプリケーションのパフォーマンスが低下します。 〜90秒かかっていた一部の操作は、現在〜6分かかります。ただし、他のメトリックはどれも、システムが遅くなっていることを示すようには見えません。
これは他の誰かが経験したことですか？
はい、（特にSSDで）インデックスを再構築すると、パフォーマンスが低下する可能性があります。ほとんどの高速SSDは、少数の大きな要求ではなく、多数の小さなブロック要求を優先します。これは、伝統的な回転するRustが好むパターンとは正反対です。
高度に断片化されたBツリーがあるとします。ディスク上では何も順序付けられていないため、通常、ツリーをスキャンするために多くの8KB I/O要求を発行します。ツリーをデフラグすると、1回のリクエストで最大512KBを取得できます。 SSDは内部で8KBのチャンクに分割するため、これらの大きなリクエストはSSDでのレイテンシが高くなります（ハードドライブとは異なり、順次I/Oを発行します）。非常に多くの場合：ディスクの待ち時間が長い=クエリが遅い
以上のことはすべて、再構築前に取得していたものと同じクエリプランが実際に取得されていることを確認してください。
最後に：スペースが少ない場合を除き、SSDで実行するときにインデックスの再構築で貴重なDBA時間を浪費しているのはなぜですか？
非常に断片化されているため、アプリケーションのパフォーマンスは良好です。インデックスを再構築すると、アプリケーションのパフォーマンスが低下します。
考えられる原因は、再構築後に構造のサイズが変更された（おそらく削減された）サイズが、オプティマイザが別のプランを選択していることを意味します。オプティマイザーの原価計算モデルへの主要な入力の1つは、各計画オペレーターが処理すると予想されるページ数です。
構造内のページ数を変更すると、ハッシュまたはマージ結合を選択するオプティマイザーと、ネストされたループ（スプールありまたはなし）の戦略を簡単に区別できます。これはほんの一例です。原価計算の違いは、並列処理を使用するかどうかの決定を含む、計画の選択のすべての側面に影響を与える可能性があります。
観察している種類のパフォーマンスの違い（および物理I/Oの欠如も考慮）を作成するには、これは最も可能性の高い説明のようです（「悪い」パラメーターのスニッフィングを排除できると仮定した場合）。
そうは言っても、詳細（理想的には、再構築前後の問題の単一インスタンスの計画と詳細な指標）がないと、現在の質問はおそらく非常に意見に基づいており、このサイトではトピックから外れます。