…だったら、もっと速いのでは?私のユース ケースは、REST API をホストしている典型的な LAMP スタックです。この API は、さまざまな入力で実行される 10 (約 50 まで増加する) の異なるクエリを持つように構造化されており、その頻度は非常に速いと予想されます。クエリの結果キャッシュについては特に質問していません。個別に追求するのに十分なほど理解しているからです。私が特に懸念しているのは、アプリケーション ロジックの 95% がクライアント側の JS であり、ほとんどが小さなクエリを実行し、それらをブラウザに返して処理する大量の小さな REST リクエストが多くのことを行うことになるという事実です。要求ごとの冗長な作業の。永続的な接続を使用でき、APC または memcache で PDO プリペアード ステートメントを確認し、それを再利用できれば、
私のユースケースでもhttp://dev.mysql.com/doc/refman/5.1/en/query-cache-operation.htmlが発生する可能性が高いと思いますが、リクエストごとに送信される準備ステートメントがまだあります.
1 に答える
いいえ。
それは興味深い質問であり、私はそれを調査するのにかなりの時間を費やしました.
呼び出し間で準備済みステートメントを渡す方法はありません。
そして、正直なところ、速度の向上について話すのはそれほど素晴らしいことではありません。
パフォーマンスが気になる場合は、単なるドライバーではなく、クエリを使用してください。
パフォーマンスに影響を与えるのはクエリであり、呼び出し方法ではありません。
エラー..
あなたの質問をもっとよく読んだ後、私は考えを変えませんでしたが、注意すべき点がいくつかあります
ほとんどが小さなクエリを実行し、それらをブラウザに返して処理する大量の小さな REST リクエストは、各リクエストに対して多くの冗長な作業を行うことになります。
それは正しい。
そのため、リクエストをバッチで送信し、1 つのバッチでより多くの情報をリクエストすることで、その数を減らすことを検討してください。準備されたステートメントの違いが無視できるからではなく、かなりのネットワーク遅延が原因です。
Apache サーバーから mysql サーバーへのオーバーヘッドを大幅に削減できると期待しています。
そして、これはそうではありません。
準備されたステートメントを間違って取り、クエリキャッシュと混同しているようです。
準備されたステートメントをリクエスト間で保持することができたとしても、apache から mysql への交換には影響しません。準備されたステートメントへの後続のすべての呼び出しを実行する必要があり、リクエストを mysql サーバーに送信する必要があります。したがって、節約できるのは、最近では非常に高速なクエリの解析だけです。私は目立たない高速を意味します。