MySQLでビューを使用する場合

分析で使用するために複数の結合からテーブルを作成する場合、新しいテーブルを作成するよりもビューを使用する方が適切ですか？

ビューを使用したい理由の1つは、データベーススキーマが管理者によってRuby内から開発されており、Rubyに詳しくないことです。テーブルの作成をリクエストできますが、追加の手順が必要であり、新しい結合を開発/テストする際の柔軟性を高めたいです。

SO（Rを使用する場合、SQLを使用する場合）に関連する質問への回答に従ってビューを使用し始めました。トップ投票の答えは、「データが単一のテーブルに収まるまでSQLでデータ操作を行い、残りをRで行う」ことから始まります。

ビューの使用を開始しましたが、ビューに関するいくつかの問題に遭遇しました。

1. クエリははるかに遅い
2. ビューは、分析に使用する実稼働データベースからバックアップデータベースにダンプされません。

ビューはこの用途に適していますか？もしそうなら、パフォーマンスのペナルティを期待すべきですか？ビューのクエリを高速化する方法はありますか？

MySQLのビューは、2つの異なるアルゴリズムのいずれかを使用して処理されます：MERGEまたはTEMPTABLE。MERGE適切なエイリアスを使用した単純なクエリ拡張です。TEMPTABLEはまさにそのように聞こえます。ビューは、WHERE句を実行する前に結果を一時テーブルに入れますが、インデックスはありません。

「3番目」のオプションはUNDEFINED、適切なアルゴリズムを選択するようMySQLに指示します。MySQL MERGEはより効率的であるため、使用を試みます。主な注意事項：

MERGEアルゴリズムを使用できない場合は、代わりに一時テーブルを使用する必要があります。ビューに次の構造のいずれかが含まれている場合、MERGEは使用できません。

• 集計関数（SUM（）、MIN（）、MAX（）、COUNT（）など）

• 区別する

• GROUP BY

• 持っている

• 限定

• UNIONまたはUNION ALL

• 選択リスト内のサブクエリ

• リテラル値のみを参照します（この場合、基礎となるテーブルはありません）

[ソース]

VIEWSがTEMPTABLEアルゴリズムを必要としているため、パフォーマンスの問題が発生していると思います。

ここで本当に古いブログ記事のMySQL内のビューのパフォーマンスに、よくなってきていないようです。

ただし、トンネルの終わりに、インデックスを含まない一時テーブルの問題（テーブル全体のスキャンが発生する）について多少の光があるかもしれません。で5.6：

FROM句のサブクエリにマテリアライズが必要な場合、オプティマイザは、マテリアライズされたテーブルにインデックスを追加することにより、結果へのアクセスを高速化できます。...インデックスを追加した後、オプティマイザは、マテリアライズされた派生テーブルをインデックス付きの通常のテーブルと同じように扱うことができ、生成されたインデックスから同様に恩恵を受けます。インデックス作成のオーバーヘッドは、インデックスなしのクエリ実行のコストと比較して無視できます。

@ypercubeが指摘するように、MariaDB 5.3は同じ最適化を追加しました。この記事には、プロセスの興味深い概要が記載されています。

最適化が適用されると、派生テーブルを親SELECTにマージできませんでした。これは、派生テーブルがマージ可能なVIEWの基準を満たしていない場合に発生します

ビューはセキュリティツールです。特定のユーザーまたはアプリケーションにデータテーブルの場所を知らせたくない場合は、必要な列のみを含むビューを提供します。

ビューは常にパフォーマンスを低下させるので、同様のクエリはビューではなくストアドプロシージャと関数である必要があります。

クエリチューニングを行うには、常にベストプラクティスに従い、WHERE句で関数を使用することを避け、選択を高速化するためにインデックスを作成します。ただし、インデックスを悪用しないでください。

あなたを助けることができる良いドキュメントがあります：http : //www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234

ビューは、複数のテーブルクエリから克服するためにテーブルを1つにマージするための事前定義された構造（データなし）であり、実際のデータから使用して迅速なリレーショナルクエリを実現できると思います...