それで、私はしばらくの間 django アプリケーションを構築しており、ORM のみを使用し、カスタム SQL を作成することはありませんでした。
ユーザー固有のコンテンツ (写真、友達、その他のデータなど) が大量にあると、サイトのメイン ページ (ユーザーが 80% ～ 90% の時間を費やす主要なインターフェイス) が遅くなっていました。
だから私はSQLロガー（pinaxにプリインストールされていたので、設定で有効にしただけです）をポップして、500以上のデータベースクエリを報告したときの驚きを想像してみてください!! 手でコード化された SQL では、最も複雑なページで 50 以上を実行することはほとんどありませんでした。
後から考えると、すべてが驚くべきことではありませんが、これは良いことではないようです。
...たとえ 10 ミリ秒以上かかるクエリが 12 程度しかなくても
だから、mysql への往復でどれくらいのオーバーヘッドがあるのだろうか? django と mysql は同じサーバー上で実行されているため、ネットワーク関連のオーバーヘッドは発生しません。
各クエリのオーバーヘッドは全体像の一部にすぎません。ほとんどのクエリは 1 ミリ秒未満で返されるため、Django サーバーと Mysql サーバー間の実際の往復時間はおそらく非常に短いでしょう。より大きな問題は、データベースに対して発行されるクエリの数がすぐにそれを圧倒する可能性があることです. 1 ページに対して 500 のクエリは多すぎます。10 人のユーザーが複雑なページを表示すると、最大 5000 クエリになります。
データベース サーバーへのラウンドトリップ時間は、発信者がワイド エリア ネットワークからデータベースにアクセスしている場合に重要な要素となり、ラウンドトリップは簡単に 20 ミリ秒から 100 ミリ秒になります。
私は間違いなく、ある種のキャッシングの使用を検討します。
クエリの量を減らす方法はいくつかあります。
とを使用.filter()し.all()て、たくさんのものを取得します。ビュー関数（またはを介してテンプレート）で選択します{%if%}。Pythonは、MySQLよりも高速に行のバッチを処理できます。
「しかし、私はテンプレートにあまりにも多くを送ることができました」。本当ですが、実行するSQLリクエストは少なくなります。どちらが優れているかを測定します。
これは、SQLを作成したときに行っていたことです。それは間違いではありません-それはORMを壊しません-しかしそれは基礎となるDB作業を最適化し、処理をビュー関数とテンプレートに入れます。
テンプレートでのクエリナビゲーションは避けてください。{{foo.bar.baz.quux}}を実行すると、SQLを使用して、にbar関連付けられfoo、次ににbaz関連付けられbar、次ににquux関連付けられbazます。.filter()ビュー関数で有用なタプルをアセンブルするための慎重なPython処理を行うことで、このクエリビジネスを減らすことができる場合があります。
繰り返しになりますが、これはSQLを手作りしたときに行っていたものです。この場合、ビュー関数でORM管理対象オブジェクトのより大きなバッチを収集し、多数の個別のORM要求を介する代わりに、Pythonでフィルタリングを実行します。
これはORMを壊しません。これにより、使用プロファイルが多くの小さなクエリからいくつかの大きなクエリに変更されます。
データベース呼び出しには常にオーバーヘッドがあります。あなたの場合、アプリケーションとデータベースが同じマシン上にあるため、オーバーヘッドはそれほど悪くないため、ネットワークの待機時間はありませんが、それでもかなりのコストがかかります。
データベースにリクエストを送信すると、次のような多くのことを実行して、そのリクエストにサービスを提供する準備をする必要があります。
これは、ほとんどのデータベース管理システムが SQL 要求を処理するために行うことの概要にすぎません。クエリ自体が比較的高速に実行される場合でも、このオーバーヘッドは 500 回発生します。結論として、データベースとローカル データベースの間の対話は、期待するほど安くはありません。