≡En resumen
- Una query cache guarda el resultado de una consulta y lo sirve de nuevo si llega exactamente la misma, sin ejecutarla.
- La caché de consultas nativa de MySQL se eliminó en MySQL 8.0 porque no escalaba en servidores con muchos núcleos y mucha escritura.
- Invalidar la caché es el problema central: cualquier cambio en una tabla vacía los resultados guardados de esa tabla.
- Hoy lo habitual es cachear en la aplicación, con claves y tiempos de expiración propios, en Redis o Memcached.
- Antes de cachear, revisa índices y consultas lentas: una caché puede esconder un problema de rendimiento en lugar de resolverlo.
01 ¿Qué es la query cache o caché de consultas?
Es un tipo concreto de caché: no guarda páginas ni archivos, sino resultados de consultas. El término se asocia sobre todo a la función nativa de MySQL, pero hoy se usa también para cualquier capa que cachee resultados de consultas, esté en el servidor de base de datos, en un proxy o en el código de la aplicación.
02 Cómo funciona una caché de consultas
-
1
Llega una consulta
El sistema calcula una clave a partir del texto de la consulta (y, en una caché de aplicación, de sus parámetros).
-
2
Busca la clave en la caché
Si existe (acierto o hit), devuelve el resultado guardado sin tocar las tablas.
-
3
Si no existe, ejecuta
En un fallo (miss) la consulta se ejecuta normalmente y su resultado se guarda para la próxima vez.
-
4
Invalida cuando cambian los datos
Cuando se modifican las tablas implicadas, o vence el tiempo de vida (TTL), la entrada se borra para no servir datos obsoletos.
03 Por qué MySQL 8.0 eliminó la query cache
| Fecha | Hito |
|---|---|
| MySQL 5.6 (2013) | Pasa a estar desactivada por defecto por no escalar con cargas de alto rendimiento en máquinas multinúcleo |
| 30 de mayo de 2017 | El equipo de MySQL anuncia en su blog que retira el soporte en MySQL 8.0 |
| MySQL 8.0.11 (19 de abril de 2018) | Primera versión de disponibilidad general de la serie 8.0, ya sin query cache |
El manual de MySQL 8.0 lo dice sin rodeos: la caché de consultas se eliminó, junto con las sentencias FLUSH QUERY CACHE y RESET QUERY CACHE y las variables query_cache_size, query_cache_type y compañía. El modificador SQL_NO_CACHE se sigue aceptando pero no tiene efecto.
El motivo técnico es que la caché dependía de un bloqueo propio (de ahí el estado de hilo «Waiting for query cache lock», eliminado también en 8.0): con muchas conexiones y escrituras frecuentes se convertía en un cuello de botella. Además, solo mejoraba las consultas que acertaban, así que no hacía más predecible el rendimiento.
04 Alternativas actuales a la query cache
Caché en la aplicación
El código decide qué cachear, con qué clave y durante cuánto tiempo. Es la opción más flexible y la más usada hoy.
Redis o Memcached
Almacenes en memoria compartidos entre servidores. Redis se define como base de datos, caché, motor de streaming y broker de mensajes.
Proxy con caché
Herramientas como ProxySQL se sitúan entre la aplicación y MySQL y cachean resultados con un TTL configurable.
Caché del motor
El buffer pool de InnoDB guarda en memoria datos e índices de las tablas. No cachea resultados, pero evita lecturas de disco.
Caché de objetos de WordPress
WP_Object_Cache guarda resultados costosos; por defecto solo dura una petición, salvo que instales un plugin de caché persistente.
Vistas materializadas o tablas resumen
Precalculan agregados pesados (ventas por día, por ejemplo) y se refrescan de forma programada.
La documentación de Laravel propone el método Cache::remember: si la clave users existe en caché, devuelve su valor; si no, ejecuta la consulta, guarda el resultado durante los segundos indicados y lo devuelve. Con Redis como driver, esa caché la comparten todos los servidores de la aplicación.
$value = Cache::remember('users', $seconds, fn () => DB::table('users')->get());
05 Cuándo conviene cachear consultas (y cuándo no)
| Escenario | ¿Cachear? | Por qué |
|---|---|---|
| Menús, categorías, ajustes del sitio | Sí | Se leen en cada página y cambian muy poco |
| Informes o agregados costosos | Sí, con TTL | Recalcular cada pocos minutos basta |
| Stock y precios en el checkout | Con mucho cuidado | Un dato obsoleto genera errores de venta |
| Datos personales del usuario | Solo con clave por usuario | Evita mostrar datos de un cliente a otro |
| Tablas con escrituras constantes | No | La caché se invalida antes de aprovecharse |
- ✓Mide primero: activa el registro de consultas lentas y revisa los planes de ejecución.
- ✓Añade índices antes de añadir caché; el propio equipo de MySQL advertía que la caché podía enmascarar índices ausentes.
- ✓Define una estrategia de invalidación clara (por evento, por TTL o ambas).
- ✓Vigila la tasa de aciertos: una caché con pocos hits solo consume memoria.
06 Cómo saber si tus consultas necesitan caché
-
1
Activa el registro de consultas lentas
En MySQL, la variable slow_query_log y el umbral long_query_time guardan las consultas que tardan más de lo aceptable.
-
2
Analiza el plan con EXPLAIN
EXPLAIN muestra si la consulta usa índices o recorre la tabla entera. Muchas consultas lentas se arreglan con un índice, sin caché.
-
3
Cuenta cuántas veces se repiten
Una consulta rápida ejecutada cientos de veces por página pesa más que una lenta que se ejecuta una vez al día.
-
4
Mide en WordPress con un monitor de consultas
Plugins de depuración como Query Monitor listan las consultas de cada página, su tiempo y el plugin que las lanza.
-
5
Cachea y vuelve a medir
Compara el tiempo de respuesta del servidor antes y después, y revisa la tasa de aciertos de la caché.
07 Query cache y velocidad de tu web
En webs dinámicas, buena parte del tiempo de respuesta del servidor se va en consultas a la base de datos. Cachear las consultas repetidas reduce ese tiempo y la carga del servidor, y combina bien con otras capas: caché de página completa, caché del navegador y CDN. Cada capa evita trabajo a la siguiente.
En WordPress, un plugin de caché de objetos con Redis suele notarse en tiendas WooCommerce y áreas privadas, donde la caché de página no sirve. Si tu web va lenta, en la guía sobre cómo optimizar un WordPress lento tienes el orden de prioridades.
Preguntas frecuentes sobre Query cache
Es una caché que guarda el resultado de una consulta a base de datos y lo devuelve directamente cuando se repite la misma consulta, sin ejecutarla otra vez.
No. La caché de consultas se eliminó en MySQL 8.0, incluidas sus variables y las sentencias FLUSH QUERY CACHE y RESET QUERY CACHE. Ya estaba desactivada por defecto desde MySQL 5.6.
Porque no escalaba con cargas altas en servidores multinúcleo: se convertía en un cuello de botella y solo mejoraba las consultas que acertaban en caché.
Caché en la aplicación con Redis o Memcached, un proxy como ProxySQL con TTL, y sobre todo índices bien diseñados. En WordPress, un plugin de caché de objetos persistente.
Sí. MariaDB la conserva, pero está desactivada por defecto y su documentación advierte de que no escala bien con mucho tráfico en máquinas multinúcleo.
La query cache guarda resultados de consultas a la base de datos; la caché de página guarda el HTML final. La de página es más rápida, pero no sirve para contenido personalizado.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗