VIEWに対してWHERE句をつける

質問

SQLでVIEWを作成し、そのVIEWに対してSELECT文を書くときに、そのVIEWに対してWHERE句をつけるのは、パフォーマンスを必ず下げることになるのでしょうか？勝手な認識ですが、VIEWにWHERE句をつけると遅くなる場合があると聞きました。VIEWの組み方にももちろんよると思いますが、VIEWは消極的に使い、出来る限りJOINなどして結合したSQLを書くほうが無難なのでしょうか？よろしくお願いいたします。

回答No.4

Siegrune

例えば、

create view vw1 as select * from table1 where KeyCol2 = '1'

select * from vw1 where keyCol1 = 'X'
order by keyCol2
なんてすると、
select * from table1 where keyCol1 = 'X' and Keycol2 = '1'
order by keyCol3
はインデックス(KeyCol1,KeyCol2,KeyCol3)を使えるのに、
Viewを使ったほうが、インデックスを使えない
（KeyCol2が'1'を抽出してからkeyCol1='X'を洗い出すため）
なんてことが起きるかもしれません。
（この例は、SQLを解析した結果で実行計画が同じ処理となるかもしれませんが。）

なお、
SQLでVIEWを作成し、そのVIEWに対してSELECT文を書くときに、そのVIEWに対してWHERE句をつけるのは、パフォーマンスを必ず下げることになるのでしょうか？
は必ずしも下げることになるとは限りません。
where句でインデッックスを使えない場合、
Create view vw2
select * from table1 where NotIndexCol1 = 'A'
として、
select * from vw2 where NotIndexCol2 < 15
としようが、
select * from vw2 where NotIndexCol1 = 'A' and NotIndexCol2 < 15
としようがあまり変わらないはずです。
（SQL解析時間が少し早くなるかもしれませんが、体感速度の差というレベルではないはず。）

まあ、そもそも、View でwhere 句を書いて、Viewを使ったSelect句でも、where 句を書くのは
お薦めしません。（Viewが副問い合わせ扱いされる危険性があるため）
create view vw1
select * from table1 where NotIndexCol1 = '1'
して、
selcet vw1 where IndexCol1 = 12
なんてしたときに、table1 が10万件合って、IndexCol1 = 12　が10件しかなかったら
いったん、
select * from table1 where NotIndexCol1 = '1'
で数万件のワークを作って、その中からIndexCol1 = 12を探すという動きになったら
きわめて遅いだけです。（SQL解析能力に期待しましょう・・・というわけにはいかないので。）
こうなったら、
select * from table1 where IndexCol1 = 12 and NotIndexCol1 = '1'
としたほうがはるかに早い。

回答No.3

mitoneko

＞確認で申し訳ありませんが、結局、VIEWに対してWHERE句をつけても、相当複雑や件数が多い（10万件以上くらい）VIEWでない限り、パフォーマンスが落ちことは早々ないと考えてよろしいでしょうか？よろしくお願いいたします。

　そう考えて良いと思います。

回答No.2

原沢 信道（@nharasawa）

あくまでも個人的な意見ですが。VIEWを多用すると、後でロジックを解析する場合に、解析が面倒になるので、あまり使わない方が良いと考えます。ただし、便利な場合もあります、私の作っている開発支援ツールは７種類のRDBMSで動くようになっていますが、テーブル一覧等を検索したい場合は、RDBMS毎にテーブル構造が大きく異なっているので、VIEWを使って同じ構造に見せかける事でツール側のSQLを同じに出来るようにしています。

お礼

回答、誠にありがとうございます。
なるほど、確かにそのような複数のミドルウェアで動かす場合、大変発揮するVIEWですね。一つ勉強になりました。

回答No.1

mitoneko

効率を気にする時には、まず、ちゃんと動く、且つ、読みやすくメンテナンスしやすいコードを書く事が先決です。
　プログラミングしてデバッグして運用する。運用しているうちに必ず手直しや改造が発生し、その時に再び、その書いたコードを読んで理解してから修正し、またデバッグする。
　このライフサイクル全体を見れば、読むに堪えない、複雑なＳＱＬで、体感できないくらいの実行速度のアップを図るのと、使える物は何でも使って、とにかく見やすいＳＱＬを組むのと、どちらが「総合的な」効率が良いかというと、間違いなく後者です。
　そぉ言う意味では、Ｖｉｅｗは積極的に使う価値のあるツールだと思います。
　（近年、オプティマイザの性能もずいぶんよくなりました。DBMSは必要とあらば、自分で勝手にViewを展開してでも、実行順序をコントロールします。）

　ただし、Ｖｉｅｗを使用したＳＱＬを作った時に、どうしても、実行速度が実用にならないと判断された時は別です。
　まぁ、たいていは、インデックスや、下手するとテーブル設計がまずいことが速度低下の原因であることが多いですが、Ｖｉｅｗが犯人だと確定したら、その時に、初めて、Viewを使わないでSQLを構築することを考えるのが筋ですね。
　こうすれば、Viewが必ず効率を下げるかとか言う議論はある意味、無意味です。

　いわゆる「効率化」とか「最適化」というのは細心の注意と測定結果をもとに、課題に応じて計画的にやるもので、原則に従って機械的に適用するものではありません。

お礼

回答、誠にありがとうございます。
おっしゃるとおり、確かに体感速度を感じない速度向上を気にするより、後で見た時に分かり良いSQLであることが大変重要であることは、私も経験上ございます。
積極的に使うことについては、個人的な考えにより、様々なご意見はございますが、いろいろなケースで試して行きたいと思います。
確認で申し訳ありませんが、結局、VIEWに対してWHERE句をつけても、相当複雑や件数が多い（10万件以上くらい）VIEWでない限り、パフォーマンスが落ちことは早々ないと考えてよろしいでしょうか？よろしくお願いいたします。