問題タブ [table-variable]

SQL Server 2005 では、次の 2 つの方法のいずれかで一時テーブルを作成できます。

また

これら2つの違いは何ですか？@tmp がまだ tempdb を使用しているかどうか、またはすべてがメモリ内で発生するかどうかについて、矛盾する意見を読みました。

どちらのシナリオで一方が他方より優れているか?

自動インクリメント ID 列を持つ T-SQLテーブル変数(テーブルではない) があります。この変数からすべてのデータを消去し、ID 列の値を 1 にリセットしたいのですが、どうすればよいですか?

前もってスキーマを定義せずに一時テーブルを定義する方法はありますか?

ブラケットか何かが足りないのかもしれませんが、参加したままのテーブル変数から行を削除して、参加しているキーを探すのに苦労しています。値がある場合は、それを取り除きます。問題は、クエリを解析できないことです。何か案は？

SQL Server 2000 でテーブル変数にインデックスを作成できますか?

すなわち

に索引を作成できますNameか?

同じクエリ内の異なる入力変数に対して、同じテーブル関数を使用して数回結合したいと考えています。しかし、これは私の場合、テーブル変数を使用してテーブル関数から個別に選択するよりもはるかに遅いことがわかりました。

テーブル変数を回避しながら高速クエリを実行するにはどうすればよいですか?

たとえば、次のような SQL クエリがあります。

ただし、関数から個別に変数を選択し、後で結合するよりもはるかに遅くなります。次に例を示します。

これの原因は何ですか？高速なクエリを取得し、テーブル変数を回避する方法はありますか?

詳細:

これは私がやっていることと似た例にすぎませんが、関数fn_ProjectNumber(@date datetime)には4つのテーブル間の結合のようなものが含まれます...

条件に基づいてテーブル変数内の列を更新しようとしています。条件は、テーブル変数のIDが別のテーブルに存在しないことです。

これらのステートメントを含むプロシージャをコンパイルしようとすると、「スカラー変数を宣言する必要があります」というメッセージが表示されます。

NOT EXISTS句内でテーブル変数を使用するにはどうすればよいですか？

SQLServer2008を使用しています

T-SQLでテーブル変数をループする方法はありますか?

私もカーソルを使用していますが、カーソルはテーブル変数よりも柔軟性が低いようです。

カーソルと同じ方法でテーブル変数を使用できるようにしたいと考えています。そうすれば、プロシージャの一部でテーブル変数に対していくつかのクエリを実行し、後でテーブル変数の各行に対していくつかのコードを実行できます。

どんな助けでも大歓迎です。

ストアド プロシージャでテーブル変数を使用すると、パフォーマンスの問題が発生します。

実際に何が起こるかは次のとおりです。

SELECT は 138 の結果を返しますが、TABLE 変数への挿入には 1min15 かかりますが、同じ SELECT で一時テーブルを使用すると、0 秒かかります。

この動作の原因は何ですか?

First, from BOL:

Queries that modify table variables do not generate parallel query execution plans. Performance can be affected when very large table variables, or table variables in complex queries, are modified. In these situations, consider using temporary tables instead. For more information, see CREATE TABLE (Transact-SQL). Queries that read table variables without modifying them can still be parallelized.

That seems clear enough. Queries that read table variables, without modifying them, can still be parallelized.

But then over at SQL Server Storage Engine, an otherwise reputable source, Sunil Agarwal said this in an article on tempdb from March 30, 2008:

Queries involving table variables don't generate parallel plans.

Was Sunil paraphrasing BOL re: INSERT, or does the presence of table variables in the FROM clause prevent parallelism? If so, why?

I am thinking specifically of the control table use case, where you have a small control table being joined to a larger table, to map values, act as a filter, or both.

Thanks!