5

を持っている大きなユーザー定義のテーブル型変数があり129 Columnsます。
一度2000-3000 Recordsにこの変数に格納し、これをさまざまなストアドプロシージャと関数に渡して、追加のデータを取得し、同じタイプの新しい変数に変更を加えて、この新しい変数をソースSPに返します（これは、テーブルタイプが原因です）パラメータはREADONLY）としてのみ渡すことができます。

これが私のアルゴリズムです。

  SP1
  @tmp tableType
  {
        INSERT @tmp EXEC
        SP2 (@tmp)

        INSERT @tmp EXEC
        SP3 (@tmp)

  }

どちらを使うべき@table varibleか#temp table

4

2 に答える 2

4

ここに役立つ記事があります：

他の多くの技術分野と同様に、ここには「正しい」答えはありません。プロシージャの範囲を超えて存続することを意図していないデータの場合、通常は#tempテーブルとテーブル変数のどちらかを選択します。最終的な決定は、パフォーマンスと妥当な負荷テストに依存する必要があります。データサイズが大きくなるか、一時データの繰り返し使用が増えると、＃tempテーブルを使用する方が理にかなっていることがわかります。環境によっては、そのしきい値はどこにでもある可能性がありますが、上記の制限のいずれかが重大な障害となる場合は、明らかに#tempテーブルを使用する必要があります。

ただし、別の方法は、トランザクションで使用する必要のある行がGUID列を使用して示される実際のテーブルを作成することです。次に、パフォーマンスを向上させる可能性のあるパラメーターとしてGUIDのみを渡す必要があります。ただし、これはオプションではない場合があります。

両方のオプションを試して、SQLプロファイラーを見てどのオプションが最高のパフォーマンスを提供するかを確認することをお勧めします。

于 2011-07-25T12:46:28.483 に答える
2

#tmp一時的にデータを格納するためのヒープとして単に使用される場合、特に数千行しかないテーブルの場合、@と＃の違いはないと思います。

覚えておくべき唯一のことは、ある時点でテーブルにインデックスを付ける必要があると思う場合、テーブル変数にインデックスを付けることができないため、一時テーブルが明らかに選択されるということです。

それを除けば、逸話的に言えば、私は一時テーブルがテーブル変数を上回っている、またはその逆を見つけたことがありません。

于 2011-07-25T12:27:46.420 に答える