標準のクエリとテーブルインデックスのビューを使用すると、大規模なデータベースのパフォーマンスが向上しますか？
私は最近、多数のテーブルと（> 1,000000）行を含むデータベースのビューを使用すると、パフォーマンスが大幅に向上するだろうと誰かと話し合いました。
私の知る限り、ビューは単に保存されたクエリ定義であるため、これがどのようになるのかはわかりません。
これは、タイプ、ブランド、仕様などに基づいて製品のフィルタリングを可能にするWebベースのアプリに関連しており、非常に高いパフォーマンスが必要です。
クエリがアプリに効果的にハードコード化されていることを考えると、人が各クエリを手動で作成する必要があるわけではないので、ビューを使用するか、標準のクエリを実行しても、結合を使用する必要なテーブルを再実行することに違いはないと考えています。 ..
テーブルにインデックスを使用すると必要なパフォーマンスが得られると提案しましたが、テーブルの行数が約200kを超える場合、インデックスは高速化の点で役に立たないと述べていました...
インデックスの有効性を排除するテーブルサイズについてこれは正しいですか？標準のクエリでビューを使用することにより、パフォーマンスの向上はありますか？
どんな助けでも大歓迎です。
一般的に、私はあなたが正しいと思います。ビューは、DBMSのカタログに格納されているクエリにすぎません。
特定のタイプのビュー（Materialized Query Tables、MQT）は、ディスク上の行を実体化できますが、ビュー自体に問題がある（最新の状態に保つためのコスト）。これらは通常、データウェアハウスに使用され、重いOLTPにはあまり使用されません。これは、それらを維持するためのコストがかかるためです。これは、MySQLの新しい概念であり、知らなかったためです。@ Veraceは、彼のコメントの次のリンク：
頭に浮かぶもう1つのことは、統計ビューです。少なくともDb2にはこの可能性があります。つまり、ビューを統計ビューにして、そのビューの統計を更新できます。式を使用する代わりに、オプティマイザが結合の統計を取得することは非常に役立ちます。この概念はMySQLには存在しないと思います。
これらのマイナーな発言から、私はビューが一般に「はるかに優れたパフォーマンスを可能にする」と主張することは間違いなく間違っていると言えるでしょう。
インデックスに関しては、この主張はおそらく私が聞いた中で最も奇妙なものの1つだと言わざるを得ません。インデックスを使用して行にアクセスすることは、テーブル内の行に直接アクセスする場合のO(n)に比べて）O（log n）の複雑さです。したがって、テーブルが大きくなるにつれて、インデックスの利点が大きくなります。サイズは、テーブルが特定のサイズに達しても無駄にはなりません。
MySQLの
VIEWsは単なる構文上の砂糖です。同等のSELECTを記述することによるパフォーマンス上の利点はありません。INDEXesは、必要に応じて、大規模なテーブルまたは巨大なテーブルのパフォーマンスを向上させるのに優れています。インデックスは基本的に10億行のテーブルに必須です。コンサルタントの要点を証明するインデックスを見せてください。彼がそれを台無しにした方法（データ型、照合、カーディナリティなど）を説明します。
MySQLは「マテリアライズドビュー」を実装していませんが、特にデータウェアハウスアプリケーションでは、それを構築して維持する十分な理由があります。 私のようなドキュメント 。
非常に類似したスキーマを持つ「多数のテーブル」は、通常（常にではありませんが）悪い設計です。
多数の「属性」（サイズ、色、メーカーなど）を持つ「製品」がたくさんあるテーブルがある場合、検索は困難です。効率のために十分なインデックスを追加することは現実的ではありません。クエリが多すぎます。 Entity-Attribute-Valueは魅力的なモデルですが、20万製品の前でもバラバラです。 私の議論と部分的な解決策 。
（私はあなたが間違ったいわゆるDBAを聞いているという他のコメントに同意します。）
特定のテーブルとアプリケーションについてさらに詳しく知りたい場合は、詳細をお知らせください。 （そして、私は新しい質問を始めることをお勧めします。この質問は、インデックスが機能するかどうかに関する一般的な炎上戦争に変わりました。）