一時テーブルのインデックスと統計
データウェアハウスをSQL 2016にアップグレードしました。クエリストアにいくつかの非常に興味深いグラフが表示されています（この機能が大好きです！）。以下は私が見た最も奇妙な例です。同じクエリに対して22のプラン。
ETLプロセスのパフォーマンスチューニングと一時テーブルの長所と短所、および実行プランの動作にどのように影響を与えることができるかを検討しています。
私のETLプロセスは、ステージングテーブルとして標準と一時の#tablesの組み合わせを使用するいくつかのストアドプロシージャを使用します。 #tablesは通常、一度使用されてから削除されます。一部は数千行のみです。一部は数百万です。 SSMSは、不足しているインデックスがあることをお勧めしますが、小さなテーブルでは、それらを追加する努力に見合うだけの十分な違いをもたらすでしょうか？より良い統計で十分ですか？
一時テーブルの統計に関するこのBrent Ozarブログ投稿（---）と、 ストアドプロシージャの一時テーブルに関するポールホワイトの記事 を 読んだところです
#tableが照会されると統計が自動的に作成され、おそらくオプティマイザによって使用されると言われています。
私の質問は次のとおりです。＃tableにインデックスを作成することには、多くのポイントまたは利点があります。および/または：統計が一度しか使用されない場合、クエリで使用する前に、ストアドプロシージャのステップとして統計を明示的に更新する価値はありますか？.
追加の手順とオーバーヘッドは価値がありますか？その結果、実行計画が大幅に改善されるか、異なる結果になりますか？
一時テーブルにインデックスを作成することにはメリットがありますが、ステージングテーブルにはメリットがない場合があります。残念ながら、それは「依存する」答えです。テストする必要があります。ステージングテーブルとの対話方法のコードを投稿した場合、インデックスが役立つかどうかを判断するのに役立ちます。一時テーブルを別のテーブルに結合する場合など、インデックスが役立つ例があります。結合された列にインデックスを付ける場合、特に一時テーブルに多くの行がある場合、パフォーマンスが向上する可能性があります。
おそらく、一時テーブルの統計を更新する必要はありません。私が見た何千もの何千ものストアドプロシージャの一時テーブルの更新統計を見たことはありませんが、パフォーマンスの問題を解決するためにそれを追加する必要もありませんが、これは「依存する」答えでもあります。
統計だけでは十分ではありません。ストレージエンジンは、クエリ述語と一致する行に到達するための何らかの方法を備えている必要があります。たとえば、3つの行がどれであるかを判別できない場合、3つの行がテーブル内の100万の条件に一致することを知っていることには意味がありません。インデックスがない場合、唯一の戦略はテーブルスキャンです。 100万行が読み込まれます。 99.9997％は破棄されます。一致するインデックスを使用すると、ポインターをたどって、必要な3つの行だけを取り出すことができます。
数ページしか必要としない小さなテーブルでは、インデックスページを読み取るための労力を考慮する必要があります。クエリに完全に一致する非クラスタ化インデックスが2つのレベルのみを必要としているとしましょう。これは、キーに続く2ページの読み取りです。次に、クラスター化インデックスが追跡されます。これは、あと2ページの読み取りになる可能性があります。したがって、テーブル全体が4ページ未満の場合、その非クラスター化インデックスは使用されない可能性があります。