自分で維持しようとするのではなく、MySQLの組み込みクエリキャッシュを使用します。テーブルへの書き込み時に、キャッシュされたクエリをテーブルに自動的にクリアします。さらに、メモリ内で機能するため、非常に効率的です...
また、クエリをキャッシュするだけではありません。レンダリングサイクルのさまざまな段階で、アプリケーションのセグメント全体をキャッシュしてみてください。したがって、MySQLにクエリをキャッシュさせてから、個々のビュー（レンダリング）、個々のブロック、および各ページをキャッシュすることができます。次に、リクエストに基づいてキャッシュからプルするかどうかを選択できます。
たとえば、ログインしていないユーザーは、キャッシュから直接ページ全体を取得する場合があります。ただし、ログインしているユーザーは（ユーザー名などの理由で）できない場合があります。したがって、彼の場合、キャッシュからページ上のビューの1/2をレンダリングできる可能性があります（ユーザーオブジェクトに依存しないため）。キャッシュのメリットは引き続き得られますが、必要に応じて階層化されます。
本当に大量のトラフィックが予想される場合は、 Memcachedを調べる価値があります。
。 MySQLにクエリを保存させてから、すべてのユーザーランドキャッシュアイテムをmemcacheに保存します...
編集： 編集に回答するには：
単一のディレクトリが大きくなると、ファイルシステムが遅くなる可能性があります。ディレクトリごとに「名前の間隔」を設定している限り（つまり、各ディレクトリにはキャッシュファイルのごく一部しかありません）、その観点からは問題ありません。正確なしきい値に関しては、それは実際には何よりもハードウェアとファイルシステムに依存します。単一のディレクトリに大量のファイルがある場合、EXT3の速度が非常に遅くなることはわかっています（文字通り数十万のファイルを含むディレクトリがあり、stat()を実行するのに最大0.5秒かかる場合があります。 ファイルの1つはもちろん、あらゆる種類のディレクトリリストを作成します）...
ただし、別のサーバーを追加すると、キャッシュが重複するか（これは良いことではありません）、キャッシュレイヤー全体を書き換える必要があることに注意してください。 Memcachedを使用しない理由はありますか 最初から？
EDit 2： 最新の編集に答えるには：
まだ電話するのは難しいです。約15億行のデータベースを持つアプリケーションがあります（1日あたり約50万行で成長しています）。同時実行性の問題がないため、キャッシュはまったく使用しません。そして、たとえそうしたとしても、キャッシュを追加するよりも、より多くのMySQLサーバーを投入するほうがよいでしょう。どの形式のキャッシュもヒット率が非常に低いため、開発時間を追加する価値がないからです。
そして、それが私がスピードのためにキャッシュしないことに固執している理由です。キャッシュにないオブジェクトは常に存在します。したがって、これらのオブジェクトの1つでページをヒットした場合でも、高速である必要があります。経験則として、私は次の数分で再びアクセスされるものをすべてキャッシュしようとします（とにかく、他のアプリケーションで本番環境で約5分の存続時間を維持します）。そのため、その期間内にアイテムのヒット数が少ない場合、またはヒット率が非常に低い（90％未満）場合は、そのアイテムをキャッシュする必要はありません。...