MySQLのviewはデータをコピーするのですか？それともエイリアスのようなものですか？

質問

Webページのアクセスの度に、毎回大きいテーブル同士をJOINするのは効率が悪いと思います。
そのような場合、大きいテーブル同士をJOINしたVIEWを作成しておけば、データはコピーされて速度が増すのでしょうか？
それとも、データはコピーされずに、結局、SELECTされる毎に内部的に毎回JOINされているのでしょうか？

回答No.2

chukenkenkou · ベストアンサー

>100万行のテーブルのビューを作っても、ハードディスクを全く消費しない

DB格納スペースとしてはそうですが、ビュー経由で検索したときにORDER BY、GROUP BY、DISTINCTなどを行いソートが発生すれば、当然、作業用のメモリが消費されます。また、インデクスのキー以外の列を検索したり、ジョインでインデクスを有効利用できなければ、やはり作業用のメモリが消費されます。
作業用のメモリは、一時的なファイルとして、OSやRDBMSによりHDDに吐き出されることはあります。

>テーブルをJOINしたVIEWを作ったとき、そのVIEWがSELECTされる度に、毎回JOINするので、パフォーマンスアップにはならない

「ビューを経由したから」という意味では、性能改善には直結しません。
ただし、よく利用される検索パターンであったりして、DBバッファ上にデータが残っていて、結果的に実I/O減になることはあるかも知れません。
また、TEXT型やBLOB型などは、1行の情報が物理的には複数行に分割して格納されるので、ビューを経由することで、「不必要にそういった列を操作する」といった無駄は省けるかも知れません。

100万件規模のデータから、ジョインして絞り込んだ結果を、Webサービスで頻繁に利用するなら、絞り込んだ結果を実体のある表に格納しておけばどうでしょうか？
当初考えていた「ビューでジョイン」ということは、「そのビュー経由では更新しない」ということ（多くのRDBMSの制限で、MySQLも同じ）になりますから。
データの反映間隔、反映方法などの検討が必要になりますけどね。

お礼

ありがとうございました。

上記のご回答、完璧には理解していませんが、なんとなく（75%ほど）は理解しました。

> 絞り込んだ結果を実体のある表に格納しておけば・・・
それは、同じデータを別々のテーブルに重複して登録するということでしょうか？
もしそうであれば、いわゆる正規化というのは、実際の業務では理想にすぎないということでしょうか？
実務経験に乏しくて、他の方がどのようにしてるのか、想像がつきません・・・。

ともかく、ご回答ありがとうございました。
VIEWはテーブルのコピーではないということは分かりました。ありがとうございます。

回答No.3

chukenkenkou

>もしそうであれば、いわゆる正規化というのは、実際の業務では理想にすぎないということでしょうか？

業務で通常使用するテーブルは、当然、正規化します。
大規模なシステムでそれらのテーブル群を直接、多量のユーザから参照、更新、追加、削除などが行われると性能を十分出せない場合があります。
そのため、レプリカを作って、一方を更新系、他方を参照系のみといった運用はよく行われることです。

「ジョインの結果をWebサービス中に、なるべく高パフォーマンスで参照させたい」なら、他のテーブルからジョインした結果を参照専用のテーブルに格納し、そのテーブルを参照させるようにする運用も考えられるということです。
更新等は基のテーブルで行い、定期的に参照専用のテーブルに反映させます。
ただ、ジョインした結果が100万件といった単位で、繰り返し参照されるようなデータでないなら、この方式は効果はありません。

回答No.1

chukenkenkou

ビューはあくまでも仮想の表であり、ビュー経由で操作時に、基の表を操作することになります。

補足

ありがとうございます。

ということは、

・100万行のテーブルのビューを作っても、ハードディスクを全く消費しない
・テーブルをJOINしたVIEWを作ったとき、そのVIEWがSELECTされる度に、毎回JOINするので、パフォーマンスアップにはならない

ということで、間違いないでしょうか？