ストアドプロシージャ内にテンポラリテーブルが必要な状況

Question

ストアドプロシージャ内でテンポラリテーブルを使用する必要がある状況を誰でも説明できますか？

Answer 1

複雑な結合が実際にオプティマイザをトリップして非常に高価なものにするケースがたくさんあります。オプティマイザをクールダウンする最も簡単な方法は、複雑なクエリを小さな部分に分割することです。 @table変数は常にメモリに格納されているので、#tempテーブルの代わりに@table変数を使用することについて多くの誤解があります。これは神話であり、信じられません。

また、ベーステーブルにない別のインデックスの恩恵を受ける異常値クエリがあり、そのインデックスをベーステーブルに追加することが許可されていない（または有害かもしれません）場合は、これが価値があります（たとえば、代替のクラスタ化インデックスである可能性があります）。これを回避する方法は、データを#tempテーブルに置くことです（ベーステーブルの限定されたサブセットであり、フィルタリングされたインデックスのように動作します）。#tempテーブルに代替インデックスを作成し、結合を実行します#tempテーブルに対してこれは#tempテーブルにフィルタリングされたデータを複数回使用する場合に特に当てはまります。

いくつかのデータに対して多くの更新を行う必要がある場合もありますが、ベーステーブルを複数回更新する必要はありません。 1つのクエリでは実行できないさまざまなデータに対して、複数の処理が必要な場合があります。影響を受けたデータを#tempテーブルに入れ、一連の計算/修正を実行した後、n回ではなく1回ベーステーブルに更新する方が効率的です。ここでベーステーブルに対してトランザクションを使用する場合は、長期間にわたってユーザーからロックすることができます。

もう1つの例は、リンクサーバーを使用していて、サーバー間の結合が非常に高価であることが判明している場合です。代わりに、リモートのデータをまずローカルの#tempテーブルに格納し、ローカルにインデックスを作成し、クエリをローカルで実行することができます。