ビューは単純なクエリより速いですか。
です
select * from myView
（同じresultSetを持つために）ビューを作成するためのクエリ自体よりも高速です。
select * from ([query to create same resultSet as myView])
？
ビューがある種のキャッシュを使用して単純なクエリと比較して高速になるかどうかは、私にはまったくわかりません。
Yes、ビューにはクラスタ化インデックスを割り当てることができます。割り当てた場合、結果のクエリを高速化できる一時的な結果が格納されます。
更新：少なくとも3人が私をこれに賛成しました。敬意を払いますが、私は彼らが間違っていると思います。 Microsoft自身のドキュメンテーションは、Viewsがパフォーマンスを向上させることができることを非常に明確にしています。
まず、単純なビューが適切に展開されているため、パフォーマンスの向上に直接貢献していません。これは事実です。しかし、インデックス付きビューは劇的にパフォーマンスを向上させることができます）。
私は直接ドキュメンテーションに行きましょう：
一意のクラスタ化インデックスがビュー上に作成された後、ビューの結果セットはすぐに実体化され、データベース内の物理ストレージに保持されるので、実行時にこのコストのかかる操作を実行するオーバーヘッドを節約できます。
第二に、これらのインデックス付きビューは他のqueryで直接参照されていない場合でも）（適切な場合はオプティマイザがテーブル参照の代わりにそれらを使用するため）有効に機能します。
繰り返しますが、ドキュメント：
インデックス付きビューは、2つの方法でクエリの実行に使用できます。クエリはインデックス付きビューを直接参照できます。さらに重要なことには、クエリオプティマイザは、ビューが最低コストのクエリプラン内の一部またはすべてのクエリに置き換えられると判断した場合にビューを選択できます。 2番目のケースでは、基礎となるテーブルとその通常のインデックスの代わりにインデックス付きビューが使用されます。クエリ実行中にビューを使用するために、クエリオプティマイザがビューをクエリで参照する必要はありません。これにより、既存のアプリケーションは、アプリケーションを変更することなく、新しく作成されたインデックス付きビューの恩恵を受けることができます。
この文書と、パフォーマンスの向上を示す図表は、 ここ にあります。
Update 2：答えは「ビュー」ではなくパフォーマンスの優位性を提供するのは「インデックス」であることに基づいて批判されています。しかし、これは容易に反論されています。
私たちは小さな国のソフトウェア会社だとしましょう。例としてリトアニアを使用します。私たちは世界中でソフトウェアを販売し、記録をSQL Serverデータベースに保存しています。私たちは非常に成功しているので、数年後には100万以上のレコードがあります。しかし、税務上、売上高を報告する必要があることが多く、自国ではソフトウェアのコピーを100部しか販売していません。リトアニアのレコードだけのインデックス付きビューを作成することで、MSのドキュメントで説明されているように、必要なレコードをインデックス付きキャッシュに保存することができます。 2008年にリトアニアの売上高に関するレポートを実行すると、深さ7のインデックス（未使用の葉を含むLog2（100））が検索されます。 VIEWなしでテーブル内のインデックスに頼るだけで同じことをした場合、検索深度21のインデックスツリーをたどる必要があります。
明らかに、ビュー自体が、単にインデックスを単純に使用するよりもパフォーマンス上の利点（3倍）をもたらします。実際の例を使用しようとしましたが、リトアニアの売上の簡単なリストが私たちにさらに大きな利点をもたらすことに気付くでしょう。
この例ではストレートBツリーを使用しているだけです。 SQL Serverがある種のBツリーを使用していると確信していますが、詳細はわかりません。それにもかかわらず、ポイントは成り立ちます。
Update 3：インデックス付きビューが基になるテーブルに配置されたインデックスを単に使用するかどうかという問題が生じました。つまり、言い換えれば、「インデックス付きビューは標準のインデックスと同等のものであり、ビューにとって新しいものでもユニークなものでもありません。」これが本当なら、もちろん、それから上記の分析は正しくないでしょう。マイクロソフトのドキュメントから、この批判が有効ではない、または真実ではないと思う理由を説明する引用を提供しましょう。
クエリのパフォーマンスを向上させるためにインデックスを使用することは新しい概念ではありません。ただし、インデックス付きビューは、標準のインデックスでは達成できない追加のパフォーマンス上の利点を提供します。
物理ストレージ内のデータの永続性に関する上記の引用や、ビューでのインデックスの作成方法に関するドキュメントの他の情報と合わせて、インデックス付きビューはnotjustと言っても安全だと思います。メインテーブルで定義されたインデックスを使用するキャッシュされたSQL Select。したがって、私はこの答えを支持し続けます。
一般的に言って、no.ビューは主に利便性とセキュリティのために使用され、速度の向上のためには使用されません。
とはいえ、SQL Server 2000以降には Indexed Views thatcanと呼ばれる特別な機能がありますが、パフォーマンスは大幅に向上します。非常に 特定のガイドラインのセット に従ってインデックス付きビューを作成する。
Books Onlineには、 表示解像度 に関する重要な参照があります。
これは インデックス付きビューの利点と作成 について説明した記事です。
Microsoft®SQL Server™は、長年にわたり、ビューと呼ばれる仮想テーブルを作成する機能をサポートしてきました。歴史的に、これらの見解はこれらの主な目的を果たしました：
ユーザーを1つ以上の基本表のデータの特定のサブセットに制限するセキュリティー機構を提供します。
開発者が実表に格納されているデータをユーザーが論理的に表示する方法をカスタマイズできるようにするメカニズムを提供します。
SQL Server 2000では、SQL Serverビューの機能が拡張され、システムパフォーマンスが向上しました。最も複雑なクエリでのデータアクセスパフォーマンスを向上させるために、ビューに一意のクラスタ化インデックスと非クラスタ化インデックスを作成することができます。 SQL Server 2000および2005では、一意のクラスタ化インデックスを持つビューはインデックス付きビューと呼ばれます。
編集：私は間違っていた、そしてあなたは見るべきである マークは答えを上にマークする。
私は SQL Server の経験から話すことはできませんが、ほとんどのデータベースでは答えは「いいえ」になります。パフォーマンスを考慮して、ビューを使用することで得られる唯一の潜在的な利点は、クエリに基づいてアクセスパスを作成できる可能性があることです。しかし、ビューを使用する主な理由は、クエリを単純化するため、またはテーブル内のデータにアクセスする方法を標準化するためです。一般的に言って、パフォーマンス上の利点はありません。私は間違っているかもしれません。
私はやや複雑な例を思い付き、自分で見てみることにします。
少なくともSQL Serverでは、クエリプランは、クエリ/ビューパラメータに基づいて、ビューと通常のSQLクエリの両方のプランキャッシュに格納されます。どちらの場合も、十分に長い期間使用されず、新しく送信された他のクエリにスペースが必要になると、キャッシュから削除されます。その後、同じ照会が発行されると、それは再コンパイルされ、計画はキャッシュに戻されます。同じSQLクエリと同じビューを同じ頻度で再利用しているのであれば、違いはありません。
明らかに、一般的に、ビューは、その性質上（ビューにするのに十分な頻度で使用されることになっていたと考えられていた）、一般に任意のSQLステートメントよりも "再利用"される可能性があります。
マテリアライズドビュー（とスキーマバインディング）を作成した方が速い場合があります。非マテリアライズドビューは、通常のクエリとまったく同じように実行されます。
SQL Serverでは実行計画を保存して、実行中に計画を立てる代わりにそれを使用することができるため、しばらくするとビューは速くなると私は理解しています。今日のパフォーマンスの向上は、以前ほど大きくはないと思われますが、このビューを使用するには多少の改善が見込まれると思います。
SQL Serverでは、ビューはネストしたクエリよりも優れています。 Mark Brittinghamの記事を読むまでは、それがなぜ良いのかを正確に知らずに、いくつかのテストを実行し、ビューとネストされたクエリを使用した場合のパフォーマンスがほぼ驚くほど向上しました。各バージョンのクエリを連続して数百回実行した後、クエリのビューバージョンは半分の時間で完了しました。私はそれが私にとって十分な証拠であると思います。
2つのクエリが同じように実行されることを期待します。ビューはストアドクエリ定義に他なりません。ビューに対するデータのキャッシュや格納はありません。実行すると、最適化プログラムは最初のクエリを2番目のクエリに効果的に変換します。
実用的な違いはなく、BOLを読むと、以前の単純なSQL SELECT * FROM Xがプランキャッシュなどを利用していることがわかります。
実行計画を保存することには、多少の利益があるはずですが、それはごくわずかです。
それはすべて状況次第です。 MS SQLインデックス付きビューは通常のビューやクエリよりも高速ですが、インデックス付きビューはミラー化されたデータベース環境（MS SQL）では使用できません。
どのような種類のループ内のビューでも、ループ内で呼び出されるたびにビューが再作成されるため、深刻な速度低下を招きます。クエリと同じです。この状況では、ループするデータを保持するために＃または@を使用した一時テーブルの方が、ビューやクエリよりも高速です。
だからそれはすべて状況次第です。
ビューの目的は、クエリを何度も使用することです。そのために、SQL Server、Oracleなどは通常、ビューの「キャッシュ」バージョンまたは「コンパイル」バージョンを提供するため、パフォーマンスが向上します。一般に、これは「単純な」照会よりも優れたパフォーマンスを発揮します。ただし、照会が非常に単純な場合は、その利点はごくわずかです。
複雑なクエリを実行している場合は、今度はビューを作成します。
ビューまたはテーブルから選択しても意味がありません。
ビューに不要な結合、フィールドなどがない場合はもちろんです。ビューのパフォーマンスを向上させるために使用したクエリ、結合、およびインデックスの実行計画を確認できます。
検索要件を早くするために、ビューにインデックスを作成することもできます。 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+
私の発見では、ビューの使用は通常のクエリよりも少し高速です。 My ストアドプロシージャ （別の大きなレコードセットと複数の結合を使って作業する）約25分かかり、ビューを使用した後（クラスタ化されていない）、パフォーマンスはわずかに速くなりましたが重要ではありませんでした。すべて。私はそれを劇的な変化にするためにいくつかの他の質問最適化技術/方法を使わなければなりませんでした。