Caché de consultas de WordPress: por qué suele hacer más mal que bien

El Caché de consulta de WordPress promete tiempos de carga más cortos, pero en la práctica suele provocar invalidaciones, Latencia y contenido inconsistente. Te voy a mostrar por qué esta caché a menudo se come el rendimiento en las configuraciones de WordPress y cómo puedo lograr una velocidad estable en su lugar.

Puntos centrales

• InvalidaciónLas operaciones de escritura frecuentes vacían la caché y generan sobrecarga.
• LatenciaLas cachés externas añaden tiempo de conexión, lo que a menudo se come cualquier ahorro.
• InconsistenciaLas entradas obsoletas dan lugar a precios antiguos, listas incorrectas o cestas de la compra vacías.
• RAMLa caché compite con PHP, MySQL y Nginx/Apache por la memoria.
• AlternativasLa caché de página, OPcache y las consultas limpias proporcionan un beneficio fiable.

Cómo funciona realmente la caché de consultas de WordPress

MySQL almacena los resultados de las consultas SELECT utilizando el texto SQL exacto en el archivo Cache y lo entrega de nuevo con una consulta idéntica, ahorrando así la ejecución. En WordPress, sin embargo, los INSERTs, UPDATEs y DELETEs se reciben continuamente, lo que carga inmediatamente la caché de consultas para las tablas afectadas. desactivado. Regularmente veo un bucle interminable en los registros: llenar, vaciar, llenar de nuevo - el servidor quema tiempo de CPU sin ningún beneficio perceptible. Además, la caché de consultas de MySQL choca con los propios mecanismos de WordPress, como los transitorios y la caché de objetos, lo que aumenta la latencia en lugar de reducirla. Aquellos que activan la caché de consultas de WordPress, por lo tanto, a menudo construyen una doble capa de caché que se rompe más rápido de lo que puede soportar.

Definición: Lo que realmente se está almacenando en caché aquí

Yo diferencio tres niveles, que a menudo se confunden:

• Caché de consultas MySQLCaché de resultados para sentencias SELECT idénticas. Cada operación de escritura en las tablas afectadas invalida las entradas. Esto es contraproducente en cargas de trabajo OLTP modernas como WordPress. En las versiones más recientes de MySQL, esta caché también está obsoleta; todavía existe en MariaDB, pero yo la desactivo allí también.
• Grupo de búferes InnoDBCaché de resultados: no es una caché de resultados, sino una caché de páginas de datos e índices. Es la ruta robusta y probada para accesos de lectura recurrentes. Un tamaño de buffer pool sólido suele rendir más que cualquier caché de resultados.
• Caché de objetos/transients de WordPressCaché del lado de la aplicación (a menudo Redis/Memcached), en la que se almacenan estructuras preparadas como resultados de WP_Query, opciones o fragmentos HTML. Esta capa solo es útil si los accesos de lectura son la norma y la invalidación funciona de forma fiable.

En el día a día, he observado que la reserva de memoria intermedia y una caché de páginas bien elegida son las mayores palancas. Una caché de consulta adicional rara vez proporciona una ganancia neta, sino que aumenta la complejidad, la latencia y el riesgo de incoherencias.

Por qué frena en lugar de ayudar

En hosts compartidos o con WooCommerce, la caché genera notables Retraso, porque cada conexión de red a Redis o Memcached cuesta tiempo y apenas produce aciertos. Incluso en máquinas rápidas, a menudo pierdo milisegundos por petición, que se acumulan con el tráfico e inflan el tiempo hasta el primer byte. Además, existe el riesgo de obtener resultados obsoletos si faltan ganchos de invalidación o los plugins funcionan incorrectamente: de repente, un cliente ve un resultado incorrecto. Precio o acciones perdidas. Si quieres echar un vistazo más de cerca, te recomiendo mi informe de experiencia Frenos de la caché de objetos porque se aplican patrones similares a los niveles de caché de consulta. Por término medio, el acceso directo limpio a la base de datos con un buen esquema y OPcache consigue tiempos de respuesta mejores y más estables.

Estampida de caché, TTL y coordinación

Un patrón recurrente en las pilas de WordPress es el Cache StampedeUna entrada caduca, muchas peticiones hacen la misma consulta cara al mismo tiempo y generan picos. Las cachés de consultas y objetos sin coordinación agravan esta situación. Yo utilizo tres estrategias para evitarlo:

• Bloqueo/Coalescencia: Una petición construye la entrada, las otras esperan brevemente o devuelven el valor antiguo (stale-while-revalidate) y se actualiza en segundo plano.
• TTL útilesNo hay normas arbitrarias de 24h. Las listas de productos o los fragmentos de precios reciben TTL cortos (segundos/minutos), los metadatos de catálogo, más largos.
• Invalidación basada en eventosEn lugar de secuencias temporales contundentes, utilizo ganchos (por ejemplo, para las actualizaciones posteriores) para eliminar sólo las claves afectadas, o mejor: para renovar específicamente la caché de la página.

Importante: En WordPress Transitorios Eficaz con caché de objetos persistente activa permanente guardado. Si no tiene una invalidación limpia aquí, creará incoherencias y patrones de error difíciles de reproducir.

Síntomas típicos en sitios productivos

Cuando la caché de consulta de WordPress está dañada, primero lo reconozco por una fluctuación de Tiempo de respuesta, que de repente sube y baja sin ningún cambio en el código. Por la tarde, cuando llegan más pedidos, se acumulan las invalidaciones y el sitio cae en una espiral de fallos de caché y nuevas entradas. La monitorización muestra entonces picos volátiles de CPU en MySQL, mientras PHP-FPM espera nuevos resultados. Al mismo tiempo, los clientes informan de desajustes como comentarios duplicados, cestas de la compra vacías o retrasos en la actualización de los widgets de los productos. También aparecen cada vez más advertencias de bloqueo en los registros porque los procesos en competencia escriben constantemente en las mismas tablas e invalidan así la caché.

Niveles de caché: secuencia en lugar de apilamiento

Priorizo los cachés según la cadena de impacto:

1. Caché del navegador/CDN/edge para páginas totalmente públicas, diferenciadas por cookies/cabeceras.
2. Caché de página en la pila (servidor web/plugin), idealmente con precarga y purga dirigida en eventos.
3. OPcache para un bytecode PHP compilado de forma consistente.
4. Caché de objetos sólo de forma selectiva para objetos caros y que rara vez cambian.
5. Base de datos con un esquema sólido, índices y una gran reserva de memoria intermedia.

Quienes siguen esta secuencia no sólo reducen la TTFB, sino sobre todo la varianza - lo que los usuarios perciben como „tirones“.

Mejores opciones de velocidad real

Gano rendimiento de forma fiable cuando Caché de página active el almacenamiento en caché de páginas, configure OPcache correctamente y, a continuación, agilice las consultas a la base de datos. La caché de páginas entrega HTML, reduce la carga de la base de datos a cero y suaviza los picos de carga. OPcache compila PHP una vez, lo que significa que PHP-FPM tiene que hacer menos trabajo y se reduce el TTFB. Una caché basada en objetos con Redis sólo merece la pena si los recursos del servidor están generosamente disponibles y la lógica de la aplicación genera pocos accesos de escritura por página. Con esta secuencia, elimino los cuellos de botella en el origen y mantengo el número de partes móviles manejable, en lugar de usar un frágil memoria intermedia mantener.

Medida	Principales ventajas	Riesgo/especialidad
Almacenamiento en caché de páginas (HTML estático)	Muy bajo TTFB, apenas carga de BD	El contenido debe actualizarse específicamente cuando se realicen cambios
OPcache (código de bytes de PHP)	Menos tiempo de CPU por Solicitar	Requiere una estrategia coherente de despliegue y calentamiento
Caché de objetos Redis	Acceso rápido a frecuentes objetos	Sólo ayuda con los golpes; consume RAM, necesita un diseño limpio de las teclas
Caché de consultas MySQL	Teóricamente menos ejecución de consultas	Elevado esfuerzo de invalidación, riesgo de incoherencia, sobrecarga adicional

Guía práctica: Desactivar y probar alternativas

Empiezo con MySQL y desactivo la caché de consultas a nivel de sistema cambiando la configuración a tipo_cache_consulta en 0 y tamaño_cache_consulta en 0 conjunto. Luego ordeno WordPress: Si un drop-in o una constante fuerza el cacheo de objetos, lo desactivo como prueba con define('WP_CACHE', false);. A continuación, utilizo herramientas como Query Monitor, Blackfire o métricas sencillas (TTFB, consultas/solicitudes, CPU) para medir el impacto real por página. Sólo cuando la caché de página está configurada y PHP/OPcache funcionan correctamente, evalúo específicamente si una pequeña capa de Redis alivia la carga en puntos calientes individuales. Esta secuencia me proporciona resultados reproducibles y garantiza Estabilidad, en lugar de esperar un golpe fortuito.

Configuraciones concretas que han demostrado su eficacia

Algunos valores por defecto con los que consigo regularmente ganancias estables (valídalo siempre en tu propio sistema):

• MySQL/MariaDB:

  [mysqld]
  query_cache_type=0
  query_cache_size=0
  innodb_buffer_pool_size=60-70%_vom_RAM
  innodb_flush_log_at_trx_commit=1
  slow_query_log=1
  long_query_time=0.2
  log_queries_not_using_indexes=1
      

  El buffer pool soporta la carga principal. Muestro el registro lento a los desarrolladores y elimino sistemáticamente los patrones N+1 y SELECT *.
• OPcache:

  opcache.enable=1
  opcache.consumo_memoria=256
  opcache.interned_strings_buffer=16
  opcache.max_accelerated_files=100000
  opcache.validate_timestamps=1
  opcache.revalidate_freq=60
  ; JIT para las pilas clásicas de WordPress más bien desactivado:
  opcache.jit=0
      

  Es importante un despliegue coherente (por ejemplo, enlaces simbólicos atómicos) y un calentamiento tras los lanzamientos.
• PHP-FPM:

  pm=dinámico
  pm.max_children=
  pm.max_requests=500-1000
  process_idle_timeout=10s
      

  Esto amortigua las fugas y la fragmentación sin provocar arranques en frío.
• Redis (si se utiliza):

  maxmemory 
  maxmemory-policy volatile-lru
  tcp-backlog 511
  ; preferido localmente a través de socket UNIX para una latencia mínima
      

  Sólo acepto Redis localmente o en el mismo AZ/host - sobre redes lentas se convierte rápidamente en un amplificador de latencia.

Mantener limpia la base de datos: Índices, consultas, plugins

Antes de apilar cachés, optimizo consultas y Índices, porque el mayor ahorro de tiempo proviene de un buen trabajo con los datos. Los JOINs demasiado largos, los SELECT *, las condiciones WHERE que faltan y la ordenación sin índice cuestan más tiempo del que puede ahorrar cualquier caché. Compruebo regularmente los plugins que almacenan muchas opciones en wp_options sin una estrategia de autoload y elimino las extensiones superfluas. Una ayuda específica puede ser ver y racionalizar sus propios patrones SQL - una introducción es proporcionada por Optimizar las consultas a bases de datos. Con una disciplina de consulta limpia, la presión sobre el servidor disminuye de forma apreciable, y el supuesto beneficio de la caché de consulta de WordPress desaparece por sí solo porque no queda nada que ocultar.

Factores de alojamiento que superan el almacenamiento en caché

Bien CPU-El rendimiento, las rápidas unidades SSD NVMe, suficiente RAM y las últimas versiones de MySQL marcan más la diferencia que una frágil caché de consultas. La configuración del servidor web también desempeña un papel importante: keep-alive, HTTP/2 o HTTP/3, tiempos de espera razonables y un conjunto de procesos PHP reducido. Me aseguro de que OPcache tenga unas dimensiones generosas para que el bytecode de los scripts frecuentes quepa por completo. Al mismo tiempo, limito los trabajos cron y las tareas en segundo plano que desencadenan tormentas de consultas durante las horas punta. Esto crea una sólida base de rendimiento sobre la que puedo utilizar el caché de páginas y el caché de objetos específicos con precisión milimétrica, sin empantanarme en frágiles...". Soluciones alternativas perder.

Métodos de medición: cómo evalúo el efecto

Primero mido el Línea de base sin caché de consulta: arranque en frío, arranque en caliente, luego de 50 a 200 peticiones con JMeter o k6. A continuación, activo específicamente un solo tornillo de ajuste, nunca varios al mismo tiempo, y repito las pruebas de carga. Registro métricas como TTFB, latencia P95/P99, consultas por petición, tasas de acierto de la caché y valores de CPU/IO. Para mí, una verdadera victoria es cuando la mediana y el P95 descienden, las tasas de error disminuyen y la varianza se reduce. En casi todos los proyectos de WordPress, este método muestra que la caché de consultas de WordPress aumenta la varianza y reduce la mediana de la tasa de error. Valor de la respuesta deteriorado.

Manual de ajuste: Umbrales y comprobaciones

• Tasa de aciertosPor debajo de ~60% visitas a la caché de objetos en tráfico productivo rara vez merece la pena. A continuación, desactivar sistemáticamente y medir de nuevo.
• Latencia de Redis>1 ms es demasiado. Se puede conseguir por debajo del milisegundo mediante un socket UNIX y un canal corto.
• Tiempos de espera DBSube Threads_running aumenta significativamente bajo carga, primero compruebo índices/consultas - no subo la caché.
• varianza: Para mí es más importante un P95 a la baja que una estadística mediana cosméticamente mejor.
• Invalidaciones: Con cada actualización de contenidos o precios, observo cuántas claves se suprimen. Los borrados amplios son un antipatrón.
• CalentamientoTras los despliegues/purgas de páginas, precaliento automáticamente las rutas críticas (página de inicio, categoría, pago).

Compatibilidad y riesgos con los plugins

Algunas extensiones sobrescriben claves de caché, borran transitorios demasiado pronto o ignoran claves de caché necesarias. Ganchos, lo que provoca entradas huérfanas. Los problemas se hacen más visibles en entornos multisitio porque se producen más eventos de escritura en paralelo y la invalidación se produce con más frecuencia. Los flujos de trabajo de comercio electrónico con precios dinámicos, vales y fragmentos de la cesta de la compra son especialmente sensibles: incluso unos pocos milisegundos de retraso pueden derribar las métricas de pago. Por lo tanto, aíslo los problemas de almacenamiento en caché desactivando gradualmente los complementos y verificándolos en puntos de medición claros. Si un complemento requiere la caché de consulta, prescindo de él y elijo una solución que funcione sin vulnerables Capa intermedia funciona limpiamente.

Seguridad operativa: desmantelamiento y mantenimiento

Mantengo los cambios de caché rollbackable. Esto significa: banderas de características para la caché de objetos/páginas, archivos de configuración separados y una lista de control para emergencias. Si algo va mal bajo carga, primero saco la caché de consulta/objeto y dejo que la caché de página + OPcache funcionen. Después de eso:

1. A ras de objetivo en lugar de globalmente: Sólo borrar las claves afectadas, no vaciar todo Redis.
2. Utilizar WP-CLI:

   wp vaciar caché
   wp transient delete --all
       

   Guarde las métricas de antemano y vuelva a medirlas.
3. Rotación de troncos y el registro de consultas lentas en lugar de activar el control de caché.

Breve resumen: Qué contrato y por qué

Desconecto la caché de consultas de WordPress por invalidación, Latencia y la incoherencia se comen el beneficio teórico. En su lugar, confío en el almacenamiento en caché de páginas, OPcache y un trabajo limpio de base de datos que ofrece resultados consistentes y sin sorpresas. Utilizo Redis de forma selectiva si hay un punto caliente claro y suficiente RAM disponible. Si se mide objetivamente, uno se da cuenta rápidamente: las consultas bien estructuradas, los recursos de host sólidos y el almacenamiento en caché de HTML proporcionan las respuestas tranquilas y rápidas que todo sitio necesita. Esto me permite mantener un rendimiento predecible, ahorrar costes de servidor en euros y evitar patrones de error que no se pueden interceptar de forma fiable con ninguna caché de consulta.