回答:
はい、ビューにはクラスター化インデックスを割り当てることができ、割り当てられた場合、ビューには一時的な結果が保存され、結果として生じるクエリを高速化できます。
更新：少なくとも3人が私にこれに反対票を投じました。すべての敬意をもって、私はそれらが間違っていると思います。マイクロソフト独自のドキュメントでは、ビューによってパフォーマンスが向上することが明確に示されています。
まず、単純なビューが適切に展開されるため、パフォーマンスの向上には直接貢献しません。 ただし、インデックス付きビューはパフォーマンスを劇的に向上させることができます。
直接ドキュメントに行きましょう：
一意のクラスター化インデックスがビューに作成されると、ビューの結果セットがすぐにマテリアライズされ、データベースの物理ストレージに保持されるため、実行時にこのコストのかかる操作を実行するオーバーヘッドが節約されます。
次に、オプティマイザが必要に応じてテーブル参照の代わりに使用するため、これらのインデックス付きビューは、別のクエリによって直接参照されていない場合でも機能します。
ここでも、ドキュメント：
インデックス付きビューは、クエリの実行で2つの方法で使用できます。クエリは、インデックス付きビューを直接参照できます。さらに重要なことに、クエリオプティマイザーは、最もコストの低いクエリプランの一部またはすべてのクエリをビューで置き換えることができると判断した場合に、ビューを選択できます。2番目のケースでは、基になるテーブルとその通常のインデックスの代わりに、インデックス付きビューが使用されます。クエリの実行中にクエリオプティマイザーがビューを使用するために、クエリでビューを参照する必要はありません。これにより、既存のアプリケーションは、それらのアプリケーションを変更することなく、新しく作成されたインデックス付きビューの恩恵を受けることができます。
このドキュメントと、パフォーマンスの向上を示すグラフは、こちらから入手できます。
更新2：パフォーマンスの利点を提供するのは「ビュー」ではなく「インデックス」であるという理由で答えが批判されました。ただし、これは簡単に反駁されます。
私たちは小さな国のソフトウェア会社だとしましょう。例としてリトアニアを使用します。私たちはソフトウェアを世界中に販売し、その記録をSQL Serverデータベースに保管しています。私たちは非常に成功しているため、数年で1,000,000以上のレコードを取得しています。ただし、税務上の目的で売上を報告する必要がある場合が多く、本国ではソフトウェアのコピーを100部しか販売していないことがわかりました。リトアニアのレコードのみのインデックス付きビューを作成することで、MSのドキュメントで説明されているように、必要なレコードをインデックス付きキャッシュに保持できます。2008年にリトアニアの売上高に関するレポートを実行すると、クエリは深さ7のインデックス（Log2（100）に未使用の葉がいくつかある）を検索します。VIEWを使用せずに、テーブルへのインデックスに依存するだけで同じことを行う場合、インデックスツリーをトラバースして、検索深度を21にする必要があります。
明らかに、ビュー自体は、インデックスのみの単純な使用よりもパフォーマンス上の利点（3倍）を提供します。私は実際の例を使用しようとしましたが、リトアニアの販売の単純なリストが私たちにさらに大きな利点を与えることに気付くでしょう。
私の例では、まっすぐなbツリーを使用していることに注意してください。SQL ServerがBツリーのバリアントを使用していることはかなり確かですが、詳細はわかりません。それにもかかわらず、ポイントは保持されます。
更新3：インデックス付きビューが、基になるテーブルに配置されたインデックスのみを使用するかどうかという問題が発生しました。つまり、言い換えると、「インデックス付きビューは標準のインデックスと同等であり、ビューに新しいものやユニークなものはありません。」もちろんこれが本当なら、上記の分析は正しくありません！この批判が有効ではない、または真実ではないと私が思う理由を示すマイクロソフトのドキュメントからの引用を提供させてください。
インデックスを使用してクエリのパフォーマンスを向上させることは新しい概念ではありません。ただし、インデックス付きビューには、標準のインデックスを使用して実現できない追加のパフォーマンス上の利点があります。
物理ストレージ内のデータの永続性に関する上記の引用と、ビューでのインデックスの作成方法に関するドキュメント内の他の情報と合わせて、インデックス付きビューは、たまたま使用されるキャッシュされたSQL Selectではない、と言っても安全だと思いますメインテーブルで定義されたインデックス。したがって、私はこの答えを待ち続けています。
一般的に言えば、いいえ。ビューは、主に利便性とセキュリティのために使用され、（それ自体では）速度の向上にはつながりません。
とはいえ、SQL Server 2000以降には、インデックス付きビューと呼ばれる機能があり、パフォーマンスを大幅に向上させることができますが、いくつかの注意点があります。
COUNT、MIN、MAX、またはをTOP。この記事では、インデックス付きビューのその他の利点と制限について説明します。
あなたはできる…
- ビュー定義は、同じデータベース内の1つ以上のテーブルを参照できます。
- 一意のクラスター化インデックスが作成されると、ビューに対して追加の非クラスター化インデックスを作成できます。
- 挿入、更新、削除、さらには切り捨てなど、基礎となるテーブルのデータを更新できます。
できません…
- ビュー定義は他のビューや他のデータベースのテーブルを参照できません。
- COUNT、MIN、MAX、TOP、外部結合、またはその他のいくつかのキーワードや要素を含めることはできません。
- 基になるテーブルと列を変更することはできません。ビューは、WITH SCHEMABINDINGオプションを使用して作成されます。
- クエリオプティマイザが何を行うかを常に予測できるわけではありません。Enterprise Editionを使用している場合は、一意のクラスター化インデックスがクエリのオプションとして自動的に考慮されますが、「より適切な」インデックスが見つかると、それが使用されます。WITH NOEXPANDヒントを使用してオプティマイザにインデックスを強制的に使用させることができますが、ヒントを使用する場合は注意が必要です。
少なくともSQL Serverでは、クエリ/ビューパラメータに基づいて、ビューと通常のSQLクエリの両方のクエリプランがプランキャッシュに格納されます。どちらの場合も、十分に長い期間使用されておらず、新しく送信された他のクエリにスペースが必要な場合、キャッシュから削除されます。その後、同じクエリが発行されると、それが再コンパイルされ、プランがキャッシュに戻されます。同じSQLクエリと同じビューを同じ頻度で再利用しているのであれば、違いはありません。
明らかに、一般に、ビューはその性質上（ビューにするのに十分な頻度で使用されると考えられていたため）、一般に、任意のSQLステートメントよりも「再利用」される可能性が高くなります。
編集：私は間違っていました、そしてあなたは上記のマークスの答えを見るはずです。
SQL Serverの経験から話すことはできませんが、ほとんどのデータベースでは答えはノーです。ビューを使用することで得られるパフォーマンスの点で唯一の潜在的な利点は、ビューがクエリに基づいてアクセスパスを作成する可能性があることです。ただし、ビューを使用する主な理由は、クエリを簡略化するため、またはテーブル内の一部のデータにアクセスする方法を標準化するためです。一般的に言って、パフォーマンス上の利点は得られません。しかし、私は間違っているかもしれません。
私は適度に複雑な例を考え出し、自分で見てみましょう。
私の理解では、SQL Serverは実行プランを保存し、その場で実行プランを理解するのではなく、それを使用するだけなので、ビューはより高速になります。今日のパフォーマンスの向上はおそらく以前ほど大きくはないと思いますが、ビューを使用するには多少の改善があると思います。
間違いなく、ビューはSQL Serverのネストされたクエリよりも優れています。（Mark Brittinghamの投稿を読むまで）なぜそれが優れているのかを正確に知ることなく、いくつかのテストを実行し、ビューとネストされたクエリを使用すると、驚くほどパフォーマンスが向上しました。クエリの各バージョンを数百回続けて実行した後、クエリのビューバージョンは半分の時間で完了しました。それは私にとって十分な証拠だと思います。
2つのクエリが同じように実行されることを期待します。ビューは保存されたクエリ定義に過ぎず、ビューのデータのキャッシュや保存はありません。オプティマイザは、実行時に最初のクエリを2番目のクエリに効果的に変換します。
実用的な違いはありません。BOLを読むと、プレーンなSQL SELECT * FROM Xがプランキャッシングなどを利用していることがわかります。
実行プランを保存しておくと、多少の利益が得られるはずですが、それはごくわずかです。
ビューの目的は、クエリを繰り返し使用することです。そのために、SQL Server、Oracleなどは通常、ビューの「キャッシュ」または「コンパイル」バージョンを提供し、その結果、パフォーマンスが向上します。一般に、これは「単純な」クエリよりもパフォーマンスが良くなるはずですが、クエリが本当に非常に単純なものである場合、利点は無視できるかもしれません。
ここで、複雑なクエリを実行している場合は、ビューを作成します。
私の発見では、ビューの使用は通常のクエリよりも少し高速です。私のストアドプロシージャの所要時間は約25分（別の大きなレコードセットと複数の結合を使用）であり、ビュー（非クラスター化）を使用した後のパフォーマンスは少し高速でしたが、まったく重要ではありませんでした。他のクエリ最適化手法/メソッドを使用して、劇的な変更を行う必要がありました。
ビューまたはテーブルから選択しても、あまり意味がありません。
もちろん、ビューに不要な結合、フィールドなどがない場合。ビューのパフォーマンスを向上させるために使用されるクエリ、結合、およびインデックスの実行計画を確認できます。
より高速な検索要件のために、ビューにインデックスを作成することもできます。http://technet.microsoft.com/en-us/library/cc917715.aspx
ただし、 '％...％'のように検索している場合、SQLエンジンはテキスト列のインデックスからメリットを得られません。ユーザーに「...％」のような検索を強制することができれば、それは高速になります
aspフォーラムで回答を参照：https : //forums.asp.net/t/1697933.aspx? Which+is+faster+when+using+SELECT+query+VIEW+or+Table+
すべての期待に反して、状況によってはビューがかなり遅くなります。
これを最近発見したのは、別のフォーマットに変換する必要があるOracleからプルされたデータに問題があったときです。たぶん20kのソース行。小さなテーブル。これを行うために、Oracleデータを変更せずにテーブルにインポートし、ビューを使用してデータを抽出しました。それらの見解に基づく二次見解がありました。多分3-4レベルのビュー。
おそらく200行を抽出した最後のクエリの1つは、45分以上かかります。そのクエリは、一連のビューに基づいていました。多分3-4レベルの深さ。
問題の各ビューを取得し、そのSQLを1つのネストされたクエリに挿入して、数秒で実行できます。
さらに、各ビューを一時テーブルに書き込んで、ビューの代わりにクエリを実行でき、ネストされたビューを使用するよりもはるかに高速であることがわかりました。
さらに奇妙なのは、データベースにプルされるソース行の制限に達するまでパフォーマンスが良好で、数日の間に崖から落ちるだけでパフォーマンスが向上したことです。
したがって、ビューからプルするビューからプルするクエリを使用すると、ネストされたクエリよりもはるかに遅くなります-これは私には意味がありません。
私はこのスレッドに出くわし、可用性グループを使用するときに考慮すべきこととして、Brent Ozarからのこの投稿を共有したかっただけです。