誰かがMySQLimulti_query関数を、3つの別々のクエリをループするよりも優れていると主張する回答で持ち出しました。私はこれに対するある種の答えをグーグルで試しましたが、私の好奇心を本当に満足させるものは何も得られませんでした。
だからここに私が疑問に思っていることがあります：
データベースを100万アイテムごとに3回ヒットし、それを1つの巨大なオブジェクトに粉砕することは、メモリ使用量には適していないことを知っていますが、データベースが存在する理由が必要であることはわかっています。避けるべきです。必要に応じてそれをトリックのバッグに入れることができるように、それをよりよく理解したいと思っています。
御時間ありがとうございます！
What is multi_query doing under the hood?- 一度に 1 つずつではなく、一度にすべてのクエリをサーバーに送信し、すべての結果を一度に取得します。それ以上に複雑なことはありません。
Does multi_query simply hit the server x number of times and aggregates the results?- サーバーに 2 回「ヒット」します。1 回目はクエリを送信し、もう 1 回は結果を取得します。
Is there a case where single queries may be more efficient than multiple queries?-「効率的」をどのように定義するかによって異なります。multi_query()ネットワークでは軽いですが、メモリは重いためquery()、ループで実行されます。逆もまた同様です。
大規模な結果セットを返す多くのSELECTステートメントでは、メモリ消費の損失がネットワークの観点からの利益を大幅に上回る可能性が高く、ほとんどの場合、クエリを発行して結果セットを一度に 1 つずつ処理する方がよいでしょう。これは、データで何をしているかによって異なります。ただし、多くのステートメントを実行する必要がある場合は、戻り値が成功/失敗のみであり、メモリ消費が少ないため、より良いUPDATE可能性があります。multi_query()
何をしているのか、予想される所要時間、(データベース) サーバーとクライアント間のネットワーク遅延、サーバーとクライアントで利用可能なリソース (主にメモリ) など、すべての要因を比較検討する必要があります。など、ケースバイケースで対応します。
少し前に行われたいくつかのパフォーマンス テストのこの記録を見つけました。結論として、 を使用することで全体的な効率が向上することがわかりmulti_query()ます。ただし、テスト ケースは単純に 4 つのクエリを実行し、それぞれが 1 つSELECTの結果を返すだけであり、「より効率的」の定義は単純に「高速」です。より多くのクエリやより大きな結果セットのテストはありません。速度は重要ですが、それがすべてではありません。無制限の量のメモリを与えれば、何でも信じられないほど高速に実行できますが、同時に何かをしようとすると、惨めに失敗します。また、単一のJOINed クエリで最終結果を得ることができるため、これは実際のテストではありません。ただし、興味深い読み物になります。
個人的には、これはややアカデミックだと感じています。なぜなら、大量のステートメントを一度に実行している場合、 90% の確率で、渡されるデータのみが異なり、クエリ構造は同じままであるためです。これは明らかな候補です。準備済みステートメント用。