そこで私は、複雑な結合または二重トリプルクエリのいずれかでクエリされることが多い3〜5の異なるテーブルがある会社で働き始めました（私はおそらくここで働き始める4人目です、それは非常に厄介です）。
とにかく、他の3つまたは5つのテーブルに同時にクエリを実行すると、通常そこに挿入される情報とともにそのデータがテーブルに挿入されるテーブルを作成しました。これにより、多くのアプリケーションのページ速度が大幅に向上しました。ここで間違いを犯したのではないかと思います。
将来的には、他のテーブルへの挿入を削除し、開始したテーブルにすべての情報を挿入し、アプリケーションをその1つのテーブルに切り替えることを望んでいます。はるかに高速です。
すべての情報を1つの大きなテーブルにグループ化する方がはるかに高速である理由と、この方法で行うことの欠点があるかどうかを誰かに教えてもらえますか？
結合が遅い場合は、テーブルにFOREIGN KEYリレーションシップとインデックスが適切に定義されていないことが原因である可能性があります。以前にテーブルが適切に正規化されていた場合、適切なインデックス付けでパフォーマンスが低下しない限り、テーブルを単一のテーブルに非正規化することはおそらくお勧めできません。 制約では、PKテーブルと関連するFK列の両方にインデックスを付ける必要があるため、制約がまだ存在しない場合にそれらを定義するだけで、パフォーマンスの向上に大いに役立つ可能性があります。FOREIGN KEY
最初のアクションは、非正規化を開始する前に、テーブルの関係が正しく定義され、テーブルにインデックスが付けられていることを確認することです。
マテリアライズドビューと呼ばれる概念があります。これは、ビューのクエリの結果を一時テーブルに格納することにより、結果セットが決定論的であるビューまたはクエリの一種のキャッシュとして機能します。MySQLはマテリアライズドビューを直接サポートしていませんが、マルチテーブルクエリからすべての行を選択し、出力をテーブルに格納することで、マテリアライズドビューを実装できます。そのテーブルのデータが古くなったら、新しい行セットで上書きします。頻繁に変更されないデータを表示するために使用される単純なSELECTクエリの場合、この方法を使用してページの読み込みを高速化できる場合があります。ただし、絶えず変化するデータに使用することはお勧めできません。
マテリアライズドビューの適切な使用法は、サイトのドロップダウンリストに入力する行を作成したり、週に1回だけ実行される複雑なレポートの結果を保存したりすることです。それらの悪い使用法は、顧客の注文情報を保存することであり、これにはタイムリーなアクセスが必要です。
テーブルの構造などを見ないと、当て推量になります。しかし、データベースが過度に正規化されている可能性があります。
それを見ずに問題が何であるかを正確に言うのは難しいです。ただし、テーブルへのインデックスと外部キーの追加を検討することをお勧めします。
すべてのデータを含むテーブルを追加する場合は、データベースを非正規化している可能性があります。
テーブルの非正規化に利点がある場合もありますが、問題が本当にテーブルスキーマにあるのか、クエリの記述方法にあるのかを調べたいと思います。クエリがインデックスを利用しているかどうか（またはインデックスをテーブルに追加する必要があるかどうか）、元のクエリライターが、クエリをより効率的にするために結合を使用できたときに副選択を使用するなどのことを行ったかどうかを知る必要があります。
正当な理由がない限り、物事が速くなるので、非正規化するだけではありません。
新しく定義したテーブルにデータの個別のコピーを用意することは、パフォーマンスを向上させる有効な方法ですが、一方で、テーブルと他のテーブルのデータを同じに保つことに関しては、完全に混乱する可能性があります。更新/削除に関して、この「キャッシュ」を無効にする方法がわからないまま、基本的に2つの真実があります。
MySQLの「正規化」と「EXPLAIN」の詳細を読んでください。他のクエリが遅い理由がわかり、データをコピーする代わりに、適切なインデックスと外部キーがほとんどない可能性があります。