これは少し未解決の質問ですが、人々の意見を聞きたいです。
明示的に宣言された一時テーブル (テーブル変数または通常の #tmp テーブル) を使用することはめったにありません。そうしないと、T-SQL がより簡潔で読みやすく、デバッグ可能になると信じているからです。また、必要な場合 (クエリで派生テーブルを使用する場合など) に一時ストレージを使用するよりも、SQL の方が優れた仕事をすることができると思います。
唯一の例外は、データベースが一般的なリレーショナル データベースではなく、スター スキーマまたはスノーフレーク スキーマである場合です。最初にファクト テーブルにフィルターを適用してから、結果の一時テーブルを使用してディメンションから値を取得することをお勧めします。
これは一般的な意見ですか、それとも反対の意見を持っている人はいますか?
一時テーブルは、レポートや ETL ジョブなどの複雑なバッチ プロセスに最も役立ちます。一般に、トランザクション アプリケーションでそれらを使用することはほとんどありません。
複数の大きなテーブルを含む結合で複雑なクエリを実行している場合 (おそらくレポートの場合)、クエリ オプティマイザーは実際には 1 回のヒットでこれを最適化できない可能性があるため、ここでは一時テーブルが優先されます。クエリは一連のクエリに分解されます。クエリオプティマイザーが計画を台無しにする機会を少なくする単純なもの。場合によっては、単一の SQL ステートメントではまったく実行できない操作があるため、ジョブを実行するには複数の処理手順が必要になります。ここでも、より複雑な操作について説明しています。
中間結果用の一時テーブルを作成してからテーブルにインデックスを付けることもできます。場合によっては、クラスター化インデックスを配置して、後続のクエリを最適化することもできます。これは、データベース スキーマにインデックスを追加することを許可されていないシステムでレポート クエリを最適化するための、手っ取り早い汚い方法でもあります。SELECT INTO は、このタイプの操作に役立ちます。これは、ログが最小限に抑えられ (したがって高速であり)、select と insert の列を揃える必要がないためです。
その他の理由には、CROSS APPLY および xpath クエリを使用して XML フィールドからデータを抽出することが含まれる場合があります。一般に、これを一時テーブルに抽出してから一時テーブルで作業する方がはるかに効率的です。また、クエリを再評価するのではなくクエリ結果を具体化するため、一部のタスクでは CTE よりもはるかに高速です。
注意すべき点の 1 つは、一時テーブルは、クエリ エンジンが中間の結合結果を格納するために使用する構造とまったく同じであるため、一時テーブルを使用してもパフォーマンスが低下することはないということです。また、一時テーブルでは、セット操作を使用したマルチフェーズ タスクが可能になり、T-SQL コードでカーソルがほとんど (完全ではありませんがほとんど) 不要になります。
「コードのにおい」は大げさですが、一時テーブルを含む多くの単純な操作を見たら、何が起こっているのか疑問に思うでしょう。
それは本当にあなたが何をしているかに依存します。私は通常、それらを回避しようとしますが、複数の手順を必要とする複雑なことを行う必要がある場合もあります。一般に、これはテーブルからの単純な選択をはるかに超えています。他のものと同様に、いつ使用するかを知っておく必要があるツールです。
私は通常、舞台裏でデータベースに処理を任せることに同意しますが、最適化がオフになっていて、手動で実行する必要がある場合があります。
一時テーブルは、最後の手段としてのみ使用される SQL コードの匂いのようなものだと思います。最終的な結果セットを取得する前にデータをキャッシュする必要がある場合は、通常、DB 設計が不適切であることを示しています。
一時テーブルには確かに適切な用途があります。正しく使用されていれば、コードの臭いではありません。それらの優れた点の 1 つは、通常、単純復旧モデルに設定されている tempdb に存在することです。これは、一時テーブルを適切な用途 (主に一括操作) に使用している場合、本番データベースのテーブルで同じ操作を行う場合と比較して、生成されるログの量が最小限であることを意味します。完全復旧モデル。
別のポスターが示唆したように、実稼働データベースが適切なハードウェア上にあるが、tempdb がそうでない場合は、DBA に移動するよう依頼してください。SQL Server 自体はクエリを処理するために tempdb をかなり使用するため、tempdb が高パフォーマンスのホームを持つことが重要です。
テーブル変数はまったく別の生き物です。彼らは記憶の中でのみ生きています。CROSS APPLY を使用して、クエリの各行に対して呼び出す必要がある関数がある場合に、これらを使用すると便利です。その関数が高価であるが、そこから取得できるさまざまな結果の数が少ない場合、すべての可能な呼び出し (またはおそらくデータセットのすべての可能な呼び出し) の結果を事前に計算し、それを. CROSS APPLY を使用する代わりに、そのテーブル変数に結合します。