ランダムなインデックスを作成して削除すると、このパフォーマンスの問題が修正されるのはなぜですか？
17,093,139行の大きなヒープテーブルがあります。このテーブルは、データベースで最も頻繁に使用されるテーブルです。これはヒープテーブルであるため、このテーブルには非クラスター化インデックスしかありません。このテーブルの断片化されたインデックスを定期的に再構築/再編成します。
現在、私たちはこの問題に頻繁に直面しています。このテーブルにアクセスする多くのクエリが突然通常よりも長くかかり始めるでしょう。確認すると、クエリの実行プランが変更されていることがわかります。
ランダムな非クラスター化インデックスを作成して削除すると、問題が解決します。
私が得ていないのは、これらの突然のスローダウンをいつでもランダムに引き起こしているもの、およびインデックスの作成と削除をバックグラウンドでテーブルに実行して、インデックスの再構築ジョブが実行しないテーブルを修正することです。
毎回この問題を修正するためにインデックスを作成したり削除したりするだけでは済まないため、恒久的な解決策を見つけることができるように、これらのスローダウンを正確に引き起こしているものを見つける必要があります。
ここでどんな助けでも大歓迎です。
テーブルのインデックスを削除すると、このテーブルを参照する実行プランがキャッシュからフラッシュされます。 （インデックスには、クエリで参照される列が含まれている必要があると思いますが、それについて100％確実ではありません）。
SQLは、問題を「修正」する新しい実行計画を作成します。
（インデックスを削除する代わりに）統計を再構築するか、実行プランを手動で削除することができます（コマンドを簡単に取得するには、Sp_blitzストアプロシージャを参照してください）。おそらく同じ動作になります（クエリ修正）。もしそうなら、あなたはパラメータスニッフィング問題を読むことを望むかもしれません。
追伸これは、クラスタインデックスのないテーブルを作成するのに適していることはめったにありません。通常、私が見た唯一の良いケースは、挿入を本当に迅速に実行したいログテーブルの場合です...しかし、あなたのケースでは、非クラスター化インデックスがある場合、とにかく挿入のオーバーヘッドが発生します。
あなたが目撃している可能性があるのは、おそらくパラメータのスニッフィングと関係があるでしょう-
1-おそらく、遅い計画をキャプチャして、後で比較するために保存する必要があります
Uが保存したプランが遅い特定のプロセスがわかっている場合は、その特定のプランをキャッシュからフラッシュしてみてください。
それが速い場合は、新しいプランを保存します。
2つの計画を比較し、異なる結果が見られる場合のパラメーター値を確認します。
これに基づいて、さらに進めることができます。しかし、その前に、これが本当に当てはまるかどうかを知っておくとよいでしょう。