web-dev-qa-db-ja.com

MySQLでビューを使用するのはいつですか？

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

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

SO（ Rを使用する場合、SQLを使用する場合 ）の関連質問に対する回答に従って、ビューの使用を開始しました。トップ投票の回答は「do theデータが単一のテーブルになるまでSQLでデータ操作を行い、残りをRで行います。」

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

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

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

mysqloptimizationview
59
David LeBauer

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

'third'オプションはUNDEFINEDで、MySQLに適切なアルゴリズムを選択するように指示します。 MySQLはより効率的であるため、MERGEを使用しようとします。主な警告：

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

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

  • 明確な

  • GROUP BY

  • 持っている

  • 限定

  • UNIONまたはUNION ALL

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

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

[src]

私はあなたのVIEWSがTEMPTABLEアルゴリズムを必要とし、パフォーマンスの問題を引き起こしていると思います。

MySQLでのビューのパフォーマンスに関する 本当に古いブログ投稿 を以下に示します。改善されているようには見えません。

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

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

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

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

45
Derek Downey

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

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

クエリのチューニングを行うには、常にベストプラクティスに従い、WHERE句で関数を使用しないようにし、インデックスを作成して選択を高速化しますが、インデックスが挿入、更新、削除を低下させないようにしてください。

役立つドキュメントがあります： http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234

15
Rainier Morilla