私は API に取り組んでいますが、質問があります。データベースクエリを節約するために の使用法を調べていましたがselect_related()、実際には、より大きく複雑なクエリを犠牲にして、実行されるデータベースクエリの量を減らすのに役立ちます。
私の質問は、使用するselect_related()とメモリ使用量が増えるのですか? いくつかの実験を実行すると、実際にこれが事実であることに気付きましたが、その理由は不思議です。を使用するかどうかに関係なくselect_related()、応答にはまったく同じデータが含まselect_related()れます。
キャッシングのせい？同じモデル インスタンスをキャッシュするために別のデータ オブジェクトが使用されているのではないでしょうか。他に何を考えるべきかわかりません。
それはトレードオフです。データベースにクエリを送信し、データベースが結果を準備してから、それらの結果を送り返すには時間がかかります。select_relatedこのプロセスの最もコストのかかる部分は、実際のクエリではなく、リクエストとレスポンスのサイクルであるという原則に基づいています。そのため、別の方法では個別のクエリだったものを 1 つにまとめて、リクエストとレスポンスが複数ではなく 1 つだけになるようにすることができます。 .
ただし、データベース サーバーの処理能力が十分でない場合 (RAM や処理能力が不足しているなど)、実際にはクエリが大きくなると、要求と応答のサイクルよりも時間がかかる可能性があります。その場合は、使用しないのではなく、おそらくサーバーをアップグレードする必要がありますselect_related。
経験則として、関連データが必要な場合は を使用しますselect_related。実際に高速でない場合は、データベースを最適化する必要があるというサインです。
UPDATE（さらに説明を追加）
データベースのクエリには、実際には複数の手順が含まれます。
適切に調整された環境 (十分なサーバー リソース、高速接続) では、プロセス全体がわずか数ミリ秒で完了します。ただし、ステップ 2 と 4 は通常、ステップ 3 よりも全体的に時間がかかります。これが、複数の単純なクエリよりも複雑なクエリの数を減らす方が理にかなっている理由です。ボトルネックは、ほとんどの場合、処理ではなくトランスポート層です。
ただし、最適化が不十分なデータベースは、大規模で複雑なテーブルを備えたパワー不足のマシン上にあり、クエリの実行に非常に長い時間がかかり、ボトルネックになる可能性があります。これは、単純なクエリを複数送信する代わりに、1 つの複雑なクエリを送信することで得られる時間の短縮を無効にすることになります。つまり、データベースは単純なクエリにより迅速に応答し、プロセス全体にかかる正味の時間は短縮されます。
それにもかかわらず、これが事実である場合、適切な対応はデータベース側を修正することです。代わりに複数の単純なクエリを送信することに戻るのではなく、データベースとその構成を最適化し、サーバー リソースを追加するなどです。