入れ子になった ORM クエリを使用するレガシー コードがあります。これは、JOIN を使用して SQL SELECT クエリを生成し、SELECT と JOIN も含む条件を生成します。このクエリの実行には膨大な時間がかかります。ちなみに、このクエリを から取得した生の SQL でDjango_ORM_query.query実行すると、妥当な時間で実行されます。
そのような場合の最適化のベストプラクティスは何ですか? リレーションを使用すると
、クエリのパフォーマンスが向上しますか?ManyToManyForeignKey
Django でのパフォーマンスの問題は、通常、複数のデータベース クエリが発生するループ内のリレーションをたどることによって発生します。django-debug-toolbarがインストールされている場合は、実行しているクエリの数を確認し、どのクエリを最適化する必要があるかを判断できます。デバッグ ツールバーには、django の最適化に不可欠な各クエリの時間も表示されます。インストールしていなかったり、使用していなかったりすると、多くの時間を逃してしまいます。
通常、リレーションをたどる問題は、select_related()またはprefetch_related( ) を使用して解決します。
通常、ページには最大で20 ～ 30 個のクエリを含める必要があり、それ以上になるとパフォーマンスに深刻な影響を与えます。ほとんどのページには、5 ～ 10 個のクエリしかありません。ラウンド トリップはデータベース パフォーマンスの最大のキラーであるため、クエリの数を減らしたいと考えています。一般に、1 つの大きなクエリは 100 個の小さなクエリよりも高速です。
データベース パフォーマンスの 2 番目のキラーは、クエリの数を減らす手法が原因で発生することもありますが、問題になることはほとんどありません。クエリが単に大きすぎる可能性があります。その場合は、defer() または only() を使用して、使用しないことがわかっている大きなフィールドをロードしないようにする必要があります。
疑わしい場合は、生のSQL を使用してください。これは、Django の世界では完全に有効な最適化です。