2012-03-15 8 views
4

私たちは、フィルタ処理後に膨大なデータを持つテーブルからレコードをフェッチする、毎日スケジュールされたストアドプロシージャを持っています。私の質問は、私はテーブル上のビューを作成し、ビューからデータをフェッチする場合、これはより速いプロセスか遅いでしょうか?ビューまたはテーブルからデータを高速に取得できますか?

答えて

6

標準ビューでは、内部SQLがクエリに展開されるだけで、違いはありません。これは、インラインのテーブル値のユーザ定義関数(「パラメータ付きビュー」と考える)にも適用されます。

ただし、indexed viewにすると、パフォーマンスが向上します。

the same applies with table-valued user defined functions 

複数ステートメントのテーブル値関数のインラインテーブル値関数のために本当ではなく、100%真実:ちょうど@AdaTheDevの答えを補完

0

。機能のこの第二のタイプは

+0

いいキャッチは、私は確かにインラインUDFを意味しました!私は非常に重要なポイントであるので、私の答えを更新します – AdaTheDev

3

だけ覚えて、それは劇的にあなたのストレージ容量を増加させることを念頭に置いて、それは助けることができる、インデックス表示について最初の1

よりも多くのリソース(メモリ)を使用しますが、負担します、ビューはselectステートメントに過ぎません(インデックス付きビューは異なります)。あなたが持っている場合:

SELECT * FROM TABLE 

をそして、それが手順にあるビューで同じものを配置し、やった場合、:

SELECT * FROM VIEW 

をプロシージャ内では、これら2つの間に違いは絶対にありません。しかし、事が複雑になって多くのテーブルに参加している場合、実際にどのようにアクセスされているかによって異なります。

たとえば、6つのテーブルにアクセスするビューを作成し、そのうちの3つのテーブルからデータを取り出す必要があるクエリを作成すると、最適化プロセス内で行われる簡略化というプロセスが役立ちます。 3つのテーブルのみを参照するプランが表示されます。しかし、そうではないかもしれません。そうでない場合は、3つの表に対して作成する問合せは、通常は3つ以上の表にアクセスするビューに対して計画よりも高速に実行されます。

ビューのネストを開始し、ビューをコールしたりビューに参加したりすると、パフォーマンスが非常に低下することがあります。

通常、ストアドプロシージャを使用している場合は、テーブルに対して直接クエリを記述することをお勧めします。パフォーマンスが損なわれることはありません。ネストされたビューの問題を回避し、シンプル化を計画するのに役立ちます。

関連する問題