Utilice el caché de consultas incorporado de MySQL en lugar de intentar mantenerlo usted mismo. Borrará automáticamente las consultas almacenadas en caché a las tablas cuando se escriban. Además, funciona en la memoria, por lo que debería ser muy eficiente...
Además, no solo almacene en caché las consultas. Intente almacenar en caché segmentos completos de la aplicación en diferentes etapas del ciclo de renderizado. Entonces puede dejar que MySQL almacene en caché las consultas, luego almacene en caché cada vista individual (renderizada), cada bloque individual y cada página. Luego, puede elegir si extraer o no de la memoria caché en función de la solicitud.
Por ejemplo, un usuario que no haya iniciado sesión puede obtener la página completa directamente desde el caché. Pero es posible que un usuario que haya iniciado sesión no pueda hacerlo (debido al nombre de usuario, etc.). Entonces, para él, puede representar la mitad de sus vistas en la página desde el caché (ya que no dependen del objeto del usuario). Todavía obtiene el beneficio del almacenamiento en caché, pero se organizará en niveles según la necesidad.
Si realmente espera mucho tráfico, definitivamente vale la pena investigar Memcached
. Deje que MySQL almacene sus consultas por usted y luego almacene todos los elementos de caché del usuario en Memcache...
Editar: Para responder a su edición:
Los sistemas de archivos pueden volverse lentos si un solo directorio crece. Mientras esté "espaciando nombres" por directorio (de modo que cada directorio solo tenga una pequeña porción de archivos de caché), debería estar bien desde ese punto de vista. En cuanto al umbral exacto, realmente dependerá de su hardware y sistema de archivos más que cualquier otra cosa. Sé que EXT3 se vuelve bastante lento si hay una gran cantidad de archivos en un solo directorio (tengo directorios con literalmente cientos de miles de archivos, y puede llevar hasta medio segundo simplemente stat() uno de los archivos, y mucho menos hacer cualquier tipo de lista de directorios)...
Pero tenga en cuenta que si agrega otro servidor, tendrá una duplicación de caché (lo que no es bueno) o tendrá que volver a escribir toda su capa de caché. ¿Hay alguna razón para no optar por Memcached? desde el principio?
Editar 2: Para responder a su última edición:
Todavía es demasiado difícil de llamar. Tengo una aplicación que tiene una base de datos con alrededor de 1500 millones de filas (con un crecimiento de alrededor de 500k por día). No usamos ningún almacenamiento en caché porque no tenemos problemas de concurrencia. E incluso si lo hiciéramos, sería mejor lanzarle más servidores MySQL en lugar de agregar almacenamiento en caché, ya que cualquier forma de caché tendría una tasa de aciertos tan baja que no valdría la pena el tiempo de desarrollo para agregarlo.
Y esa es la razón por la que estoy tan convencido de no almacenar en caché para la velocidad. Siempre habrá un objeto que no esté en caché. Entonces, si llega a una página con uno de esos objetos, aún debe ser rápido. Como regla general, trato de almacenar en caché todo lo que se accederá nuevamente en los próximos minutos (de todos modos, mantengo un tiempo de vida de aproximadamente 5 minutos en producción en otras aplicaciones). Entonces, si los elementos no obtienen más que unos pocos resultados en ese lapso de tiempo, o la tasa de resultados es muy baja (menos del 90 %), no me molesto en almacenar en caché ese elemento...
