複雑なクエリを手作業でselect [...] into #tのチェーンに分割してからselect [...] from #t [...]にすると、視覚的に高速になります。これは、悪い設計によって引き起こされた可能性があります。SQLエンジン/オプティマイザはテンポラリ・テーブルを使用してクエリを実行できますか？
それにもかかわらず、SQLエンジン/オプティマイザは、このようなテンポラリテーブルを使用することが有用であると考えているのでしょうか？
私が上記の手動分割の種類が大幅にパフォーマンスを向上させる場合は、元のビュー/基礎となるテーブルの設計に大きな欠陥があることを意味しますか？
一時テーブルのチェーンを使用しても、悪い設計ではありません。また、より良いパフォーマンスを保証するものでもありません。 tempテーブルを賢明に使用することを検討する必要があります。時にはパフォーマンスが向上し、ディスクの読み取り/書き込みが増加する場合もあります。
この種のシナリオでの一時テーブルの使用方法の1つは、低速クエリの複数の実行を排除するために一時テーブルにデータを格納することです。つまり、コード内で高価なクエリを複数回実行する場合は、コードの複数の場所でクエリを実行する代わりに、一時テーブルを使用して格納されたデータを使用することを検討する必要があります。
以外の場合は、理由コードをより理解しやすく（パフォーマンスが問題でない場合）
もう一つのケースは読みやすくするのかもしれない、あなたはあなたのデータにインデックスを追加できるように一時テーブルを使用します。そのような場合は、一時テーブルにデータを格納し、インデックスを作成して読み取りパフォーマンスを向上させます。
通常、コード内で1回だけ実行されるクエリに対しては、一時テーブルを使用しないでください。
最後に、SQL Serverはデータを格納する方法ではなく、それ自身のために一時テーブルを使用します。ですから、SQL Serverには何もしないでください。一時テーブルを使って何をしたいのですか？
の詳細はビューに基づいています複数のケースステートメントがありました。そのビューでは、集計とフィルタリング（varcharフィールドでも同様）を行います。元のビューを一時テーブルに置くと、最終的な選択のパフォーマンスが大幅に向上しました。しかし、それは1回の実行です。元のビューとその基礎となるテーブルを使用して効率を上げるべきでしょうか？ – zaptask
最終的なクエリの場合は、ビューから選択するのではなく、一時表から選択するだけで、一時表を使用してもパフォーマンスが向上しません。ビューを一時テーブルで置き換え、クエリでビューを一度使用するとパフォーマンスが向上すると思います。ただし、時にはテンポラリテーブルにデータを格納すると、SQL Serverによってより良い実行計画が生成されます。通常、これは統計情報が最新でない場合に発生します。あなたがtempテーブルを使ってより良いパフォーマンスを得るなら、それを進めてください。しかし、実行計画を見れば、この動作を説明できるはずです。 – FLICKER
#tempテーブルでフィルタリングと集約が行われています。ソースビューは 'select f1、f2、....、case ...、case ...、... t1 ... join t2 ... joint t3 ....#tempテーブルにこのビューの結果を挿入し、#tempテーブルから追加のフィルタリングと集計を選択します。実行時間は長時間から数秒に短縮されます。 – zaptask
私はこの質問が好きですが、それは少し幅があり、基本的にはSQL Serverエンジンの最適化の内部動作を説明することになります。そのような一時テーブルを使用して大きなクエリを分解し、一般にパフォーマンスを向上させます。私はそれを、より管理しやすい小規模のチャンクに大量のタスクを分割するように見ています。 SQL Serverに膨大なクエリを与えると、クエリ全体を評価して最適化します。実際に最適化された3つのクエリを与えると、SQL Serverには行う。 – Tanner
SQL Serverも同様のことを自動的に行うことができ、クエリプランのスプールとして見ることができます。 Rob Farleyの[ブログの投稿]（http://sqlblog.com/blogs/rob_farley/archive/2013/06/11/spooling-in-sql-execution-plans.aspx） –