2

私は最近、ビューの概念を紹介されましたが、複雑なクエリを部分に分割するのに非常に役立ちます。

私の質問は、ビューからクエリを作成し始めたときに、他のビューからのクエリなどの効率上の欠点があるかどうかです...

したがって、たとえば次のようになります。

view1 -> query from tables A, B & C
view2 -> query from tables D, E & F
view3 -> query joining view1 & view2

テーブル A、B、C、D、E、および F を結合する単一のクエリを設計する代わりに、view3 をクエリすると速度が低下しますか?

そして、ビュー アプローチを使用することを選択した場合、ビュー 1、ビュー 2、およびビュー 3 の設計に ORDER BY 句があるかどうか、またはどのビューにも ORDER BY 句を配置しない方がよいかどうかは重要ですか? view3をクエリするときにORDER BYを使用するだけですか？

ご助力ありがとうございます！ボガ。

4

1 に答える 1

3

詳しくは、 CREATE VIEW 構文order byを参照してください。

ORDER BY はビュー定義で許可されていますが、独自の ORDER BY を持つステートメントを使用してビューから選択する場合は無視されます。

また、ここのView Processing Algorithmsでは、MySQL プロセスがどのようにビューを選択するかを確認できます。いつものように、それは依存します。;-)

アルゴリズムは最初にビューの結果を一時テーブルにコピーし、それに対してクエリを実行するため、MERGEアルゴリズムが最も効率的であるようです。temptableただし、常にマージを使用できるとは限りません。最後のセクションを参照してください

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

  • 集計関数 (SUM()、MIN()、MAX()、COUNT() など)
  • 明確
  • グループ化
  • 持っている
  • リミット
  • UNION または UNION ALL
  • 選択リストのサブクエリ
  • リテラル値のみを参照します (この場合、基になるテーブルはありません)
于 2012-12-04T10:09:41.420 に答える