を使用して一時テーブルを作成するストアドプロシージャがある場合、tempdb
パフォーマンスを向上させるために、これらをテーブル変数に切り替える方がよいと思いますか?
3 に答える
一時テーブルはパフォーマンスが優れています。テーブル変数を使用していて、変数内のデータが大きくなりすぎると、SQLServerは変数を自動的に一時テーブルに変換します。
ほとんどすべてのデータベース関連の質問と同様に、それはあなたが何をしようとしているかに依存します。したがって、これ以上の情報がなければ答えるのは難しいです。
だから私の答えは、それを試して実行計画を見てみることです。最小のコストで最速の方法を使用してください。
オブジェクトはメモリ内にのみ存在するため、「セットアップ時間」が少なくなるため、@Tableの速度を上げることができます。
@Tablesには多くの問題があります。
@Tableに主キーを設定できますが、それだけです。列の組み合わせに対してクラスター化された他のインデックスはクラスター化されていません。
また、テーブルに実際のデータボリューム(約200行以上または1000行以上)が含まれる場合、テーブルへのアクセスは遅くなります。特に、有用なインデックスがない場合は特にそうです。
#Tablesは、デバッグ時に削除する必要があるため、procの面倒です。作成に時間がかかります。また、2番目のステップとしてインデックスを追加する必要があるため、セットアップに時間がかかります。ただし、大量のデータがある場合は、毎回その#tablesを使用します。
テーブルに100行未満のデータがある場合でも、テーブルに有用なインデックスを作成できるため、#Tablesを使用することをお勧めします。
要約すると、単純なprocなどを実行するときに簡単にするために、ほとんどの場合@Tablesを使用します。ただし、実行する必要があるものはすべて#Tableにする必要があります。
@Tablesには統計がないため、実行プランにはより多くの推測が必要です。したがって、推奨される上限は1000行程度です。#テーブルには統計がありますが、これらは呼び出しの間にキャッシュできます。REBUILD
SPを実行するたびに、また毎回、カーディナリティが大幅に異なる場合RECOMPILE
。もちろん、これはオーバーヘッドですが、ごみの計画のコストとバランスを取る必要があります。
どちらのタイプもTempDBに対してIOを実行します。
いいえ、@Tablesは万能薬ではありません。