ヒント：マルチテーブル共同問い合わせの以上3つのテーブルをお勧めしません
データアプリケーションの量、効率的なマルチテーブル共同問い合わせの開発に、しかし場合は、マルチテーブルは、テーブル内のデータのクエリ大量に参加して、時間のインデックスがありませんデカルト積は、非常に大きいであろうデータの量は、SQLの効率は非常に低くなります
複数の単一のテーブルは、サービス層に恩恵をマージする照会：
1、高いキャッシュ効率を、多くのアプリケーションは、結果オブジェクトを、対応する単一テーブルのクエリを簡単にキャッシュすることができます。関連付けは、テーブルが変更された場合、テーブルはほとんど変化しない場合は、分割した後、その後、テーブルに基づいてクエリは、クエリキャッシュの結果を再利用することができますが、あなたは、クエリキャッシュを使用することはできません。
2、マルチテーブル共同リストの情報ページのページ付け、それはマルチテーブル共同問い合わせの場合は、のみ、データの一部を表示する必要があり、それが繰り返された場合、最初に単一のテーブルをデータリンクの再実行制限のすべて、単一テーブルのクエリをチェックアウトする必要がありますスクリーニング、最初に実行した後、限界への関連付けテーブルの残りの部分と、大幅にデータ量削減ません
3、もし別個の読み取りおよび書き込みの排他的ロック・テーブルが追加されるので、高い同時実行時に、データベース（バックアップからマスタ）を書き込み、マルチ単一テーブルのクエリにテーブルサイズジョイント問い合わせはロック競合のロック還元、小さくなった後
、大量のデータの後に、4を、概してサブライブラリーサブテーブルは、データベースへの圧力を緩和するであろう方法で、複数のテーブルの上に単一テーブルクエリの使用関節のお問い合わせ簡単にサブライブラリーは、大規模な変更のSQL文を必要としない、クロスデータベースのための一般的なサポートのよりスケーラブルなミドルウェアサブライブラリーのサブテーブルが悪いの参加
5、クエリ自体の効率も向上させることができます。クエリIDセット時間は、クエリのMySQL IDの順序を可能IN（）の代わりに、リレーショナル・クエリを使用して、それがランダムアソシエーションよりも効率的であってもよいです。
6、ビジネスの成長、最も可能性の高い問題が発生したために、データベースの下、スタンドアローンのデータベースは非常に高価なコンピューティングリソースであるとして、データベースが同時にデータベースがより高いスループットなっ可能にするために、サービスへのCPUを消費する必要が読み取りおよび書き込み、
および微妙なギャップを遅らせるために数百ミリ秒を気にしないビジネスは、ビジネスを行うにはより多くのコンピューティングサービス層を置く、すべての後に、データベースを展開するためにコンピューティングリソースの良いレベルが難しいああ、これは、大量のトラフィックライトDBのですアーキテクチャ
図7は、クエリは、冗長なレコードを減らすアプリケーション層で、関連する問い合わせを行い、記録アプリケーションに対して一度だけクエリする必要があることを意味し、データベースに関連するクエリを行うことができ、あなたは、データのアクセス部分を繰り返す必要があります。
さらに、アプリケーションに関連するハッシュを達成するために、これを行うのではなく、MySQLのに関連付けられているネストされたループを使用します。いくつかのシーンに関連付けられたハッシュ効率がはるかに高いです。
複数の単一テーブルのクエリサービス層欠点をマージ：
1複数のデータベース接続を必要とする
2を、コードはより複雑です
概要：
個人的には、データの量、当然のことながら、よりスケーラブルな、複数の単一テーブルのクエリを行う方が良いと思い、より便利との共同調査の開発を指示