は私ではなく、すべての時間のJOIN CREATE VIEWを使用する必要があり

Question

私は次のクエリがあります

SELECT t.*, a.hits AS ahits 
       FROM t, a 
       WHERE (t.TRACK LIKE 'xxx') 
       AND a.A_ID = t.A_ID 
       ORDER BY t.hits DESC, a.hits DESC 

非常に頻繁に実行されます。表tは約15M +行を持ち、aは約3M +行を持っています。

上記のクエリでEXPLAINを実行したとき、私はいつも一時テーブルを作成したというメモを受け取りました。私は、上記のクエリに基づいて一時テーブルを作成するにはかなりの時間がかかることに気付きました。そして、これは十分な時間がかかります。

したがって、私は上記を使用してビューを作成する場合、私は疑問に思って言う：

CREATE VIEW v_t_a 
SELECT t.*, a.hits AS ahits 
FROM t, a 
WHERE a.A_ID = t.A_ID 

とに私のコードを変更します。

SELECT * FROM v_t_a WHERE TRACK LIKE 'xxx' ORDER BY hits DESC, ahits DESC 

それはパフォーマンスを向上させるのだろうか？テンポラリテーブルの作成時間を削除しますか？

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

Answer 1

VIEW内部では、QUERY VIEW ...のたびにTWOテーブルに参加します。これを防止するために

、MATERIALIZED VIEWを作成...

It is a view that is more of a TABLE ...You can query it directly as other table.. 

しかし、あなたはすべての基本となるテーブルのデータが変更された場合、自動的にそれを更新するために、いくつかのトリガを記述する必要があります...

この参照：http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views

を

Answer 2

ビュー内で全く同じ操作を実行すると、クエリとして実行するよりも効率的になることはまれです。

ビューは、パフォーマンスではなくクエリの複雑さを管理するためのもので、クエリが持つバックエンドで単純に同じアクションを実行します。

これには1つの例外がありますが、実際には、後続のクエリがより効率的になるように、クエリ用に別個の長寿命テーブルを作成します。

しかし、クエリのパフォーマンスが問題になる場合は、このようなスキームを自分で実装する可能性があります。

テーブルの変化率に大きく依存します。とにかくデータが頻繁に変化していると、毎回マテリアライズクエリを再生成する必要がある場合、それは価値がありません。

Answer 3

MySQLがより高度なデータベースシステムと同じ方法でVIEWを最適化すると仮定すると、非常に危険です。サブクエリと派生テーブルと同じです。MySQL 5.0は失敗し、非常に非効率的に実行されます。

MySQLにはVIEWS - クエリマージを処理する2つの方法があります。この場合、VIEWは単にマクロまたはテンポラリテーブルとして展開されます。この場合、VIEWは後でクエリで使用される一時テーブル（インデックスなし）にマテリアライズされます。実行。 外部クエリからの一時的なテーブルの作成に使用されるクエリに最適化が適用されていないようですが、複数のテーブルを同時に使用すると、インデックスを取得しないため重大な問題が発生する可能性があります。 。

あなたのアプリケーションでは、特に一時的なテーブルの実行方法を必要とするMySQL VIEWの実装には注意が必要です。 VIEWは非常に小さなパフォーマンスオーバーヘッドで使用できますが、注意が必要な場合にのみ使用してください。

MySQLには、適切に最適化されたVIEWでクエリを取得する方法があります。