MySql データベースにおける単一テーブル クエリと複数テーブル結合クエリの効率の比較

この間、プロジェクトに取り組んでいるときに、データ間の接続が非常に複雑なモジュールに遭遇しました。テーブルを作成するときに非常に混乱しました。これらの複雑なデータをどのように処理すればよいでしょうか。単一のテーブルをクエリしてから、ビジネス レイヤーでデータ間の関係を処理する必要がありますか。それとも、複数テーブル接続クエリを通じてデータの関係を直接処理する必要がありますか。

資料を調べたりブログを読んだりした結果、答えは 2 つあります。

1. 「高性能 MySQL」の回答

多くの高性能アプリケーションは、関連するクエリを分解します。簡単に言えば、各テーブルに対して単一のテーブルクエリを実行し、その結果をアプリケーションで結合するだけです。たとえば、次のクエリ:

タグから*を選択
tag_post.tag_id=tag.id の tag_post に参加
tag_post.post_id=post.id の投稿に参加
ここで、tag.tag='mysql';

代わりに次のクエリに分解できます。

tag='mysql' のタグから * を選択します。
tag_id=1234 の tag_post から * を選択します。
IDが(123,456,567,9989,8909)の投稿から*を選択します。

いったいなぜこんなことをするのでしょうか?

一見すると、これを行うメリットはありません。元のクエリはここでは複数のクエリになり、返される結果はまったく同じです。

実際、関連するクエリを分解してクエリを再構築すると、次のような利点があります。(同時実行性が高く、パフォーマンスの高いアプリケーションでは、通常、単一テーブルクエリを使用することをお勧めします)
1. キャッシュをより効率的にします。多くのアプリケーションでは、単一テーブル クエリに対応する結果オブジェクトを簡単にキャッシュできます。また、MySQL クエリ キャッシュの場合、関連付けられているテーブルが変更されると、クエリ キャッシュは使用できません。分割後、テーブルがほとんど変更されない場合は、テーブルに基づくクエリでクエリ キャッシュの結果を再利用できます。

2. クエリを分割した後、単一のクエリを実行すると、ロックの競合を減らすことができます。

3. アプリケーション層で関連付けを行うと、データベースを分割しやすくなり、高いパフォーマンスとスケーラビリティを実現できます。

4. クエリ自体の効率も向上する可能性があります。

5. 冗長なレコードのクエリを削減できます。

6. さらに、これは MySQL のネストされたリング結合を使用するのではなく、アプリケーションでハッシュ結合を実装することと同じです。シナリオによっては、ハッシュ結合の方がはるかに効率的です。

7. 単一テーブル クエリは、データ量が多い場合に、後でデータベースとテーブルを分割する場合に役立ちます。結合クエリを使用する場合は、データベースを分割したら、元の SQL を変更する必要があります。

8. 前回、CTO が自社の技術を共有しているのを見たとき、その会社では最下位レベルでの結合クエリは禁止されていると規定されていました。確かにデータが大きいと遅くなります。

9. 結合クエリは確かに高速ですが、MySQL リソースは通常、プログラム コード リソースよりもはるかに不足しています。

2. その他の回答

仮説的なシナリオ: Web サイトに企業ライブラリ セクションがあり、特定の都市にあるすべての企業を検索したいとします。

データ テーブル: tbl_company (t1)、tbl_city (t2)。

例1:

t1テーブルはcityidを格納し、idに基づいてテーブル結合クエリを実行します。

t1 から * を選択し、t2 を t1.cityid=t2.cityid で結合します。

例2:

テーブル t1 には cityName が格納されます。ユーザーがフロントエンドで Shanghai をクリックすると、Shanghai の ID がバックエンドに渡されます (cityName の渡しは考慮されません)。

ID に基づいて cityName を検索します。select cityName from t2 where cityid= #{cityid};

次に、cityName = #{cityName} である t1 から * を選択します。

2 つの違い: 例 1 では 1 つのテーブル関連付けクエリのみが実行されますが、例 2 では 2 つの単一テーブルクエリが実行されます。

データ量が多いことを考慮すると、複数テーブル結合クエリはクエリ効率に影響するため、すべて単一テーブルクエリに最適化されます。 TP: 上記はインデックスを使用していない場合です

どちらがより効率的でしょうか?

回答: SQL の最適化もビジネスに関係します。このステートメントのクエリは頻繁に行われるでしょうか? 2 つの接続によって生じるオーバーヘッドを考慮する必要がありますか? これらを考慮する必要がなく、インデックスがない場合、違いは大きくありません。2 は 1 よりわずかに優れているはずです。

データがそれほど大きくない場合は、カスケード クエリの方が高速です。

従来のデータベースの場合、データベースクエリの数を可能な限り減らします。

しかし、1. MySQL は接続/切断の処理や小さくて単純なクエリへの応答が非常に高速です。2. 今日のネットワークは非常に高速です。そのため、複数の小さなクエリの方が MySQL の方が高速になる可能性があります。

結局、マスターはどちらが優れているかについて結論を出していません。ハハ、実際、この本全体では、テスト! ベンチマーク! という 1 つの意味が明確に表現されています。自分のデータ環境で、両方の方法をテストしてください。データに語らせてください。

結論

個人的には、単一テーブルクエリを使用することをお勧めします。アプリケーション層でデータを関連付けた方が良いでしょう。

上記はMySqlの単一テーブルクエリと複数テーブル接続クエリの効率性問題の詳細です。MySqlの単一テーブルと複数テーブル接続クエリの効率性の詳細については、123WORDPRESS.COMの他の関連記事に注目してください。