MySQLがサブクエリと結合の使用を推奨しない理由

ページ分割されたクエリを実行するには:

1. MySQL の場合、サブクエリと結合の使用は推奨されません。結合の効率に欠陥があるためです。データ量が多くなると、効率を保証することが難しくなります。インデックスに基づいて単一のテーブルからデータを取得し、プログラム内でデータを結合してマージすることを強くお勧めします。
2. サブクエリを使用しないでください。効率が低すぎます。サブクエリを実行する場合、MYSQL は一時テーブルを作成し、クエリの完了後にこれらの一時テーブルを削除する必要があります。そのため、サブクエリの速度はある程度影響を受けます。一時テーブルの作成と破棄という追加のプロセスがあります。
3. JOIN の場合はネストされたクエリを使用します。小さなテーブルは大きなテーブルを駆動し、インデックス フィールドを通じて関連付けられます。テーブル内のレコード数が少ない場合は問題ありません。大きい場合は、ビジネスロジックで制御して処理できます。
4. データベースは最下層にあり、ボトルネックとなるのは多くの場合データベースです。データベースは、ビジネスに追加することなく、データ ストア ツールとしてのみ使用することをお勧めします。

1. アプリケーション層アソシエーションの利点

キャッシュをより効率的にします。多くのアプリケーションでは、単一テーブル クエリに対応する結果オブジェクトを簡単にキャッシュできます。関連付け内のテーブルが変更されると、クエリ キャッシュは使用できません。分割後、テーブルがほとんど変更されない場合は、テーブルに基づくクエリでクエリ キャッシュの結果を再利用できます。

クエリを個々の部分に分割すると、ロックの競合を減らすことができます。

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

クエリ自体の効率も向上する可能性があります。 ID セットをクエリする場合、結合クエリの代わりに IN() を使用すると、MySQL は ID の順序でクエリを実行できるため、ランダム結合よりも効率的になる可能性があります。

これにより、冗長なレコードクエリの数を減らすことができます。アプリケーション層で連想クエリを実行すると、アプリケーションは特定のレコードを一度だけクエリすればよいが、データベースで連想クエリを実行すると、

データの一部に繰り返しアクセスすること。この観点から見ると、このような再構築により、ネットワークとメモリの消費も削減される可能性があります。

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

2. アプリケーション層アソシエーションの使用シナリオ

アプリケーションが単一のクエリの結果を便利にキャッシュできる場合

異なるMySQLサーバー間でデータを分散できる場合

IN() を結合クエリの代わりに使用できる場合

同時実行シナリオが多く、DBクエリが頻繁に発生するため、シャーディングが必要です。

3. 参加が推奨されない理由

1. DB は大きなビジネス上のプレッシャーにさらされており、その負担をできるだけ軽減したいと考えています。テーブルに 100 万ページ以上ある場合、結合によってパフォーマンスが低下します。
2. 分散サブライブラリとサブテーブル。現時点では、データベース間の結合は推奨されません。現在、MySQL の分散ミドルウェアは、データベース間の結合パフォーマンスが低いです。
3. テーブル スキーマを変更します。単一テーブル クエリを変更する方が簡単ですが、結合用に記述された SQL ステートメントを変更する必要がある場合、見つけるのは簡単ではなく、コストが比較的高くなります。システムが大きい場合、保守が困難になります。

4. 結合なしのソリューション

ビジネス レイヤーでは、単一のテーブルに対してデータのクエリが実行された後、そのデータが次の単一テーブル クエリの条件として使用されます。つまり、サブクエリです。サブクエリからの結果セットが多すぎるのではないかと心配です。 MySQL では IN の数に制限はありませんが、SQL ステートメント全体のサイズは制限されます。パラメータ max_allowed_pa​​cket を調整することで、SQL ステートメントの最大値を変更できます。ビジネスを適切に処理し、単一のクエリの結果セットを許容できる範囲に制限することをお勧めします。

5. 結合クエリの利点

関連クエリの利点は、ページ付けが可能で、セカンダリ テーブルのフィールドをクエリ条件として使用できることです。クエリを実行すると、セカンダリ テーブルに一致するフィールドが結果セットとして使用され、プライマリ テーブルがその中で使用されるようになります。しかし、問題は、一致するデータの量が多すぎると機能せず、返されるページング レコードが実際のものと異なることです。解決策としては、フロント エンドに 1 回限りのクエリを渡して、フロント エンドでバッチで表示させることができます。この解決策の前提は、SQL 自体の長さが制限されているため、データの量が大きすぎないことです。

これで、MySQL がサブクエリと結合の使用を推奨しない理由に関するこの記事は終了です。関連する MySQL サブクエリと結合の詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。