Optimizar consultas MySQL en WordPress: guía completa

Por qué las consultas MySQL en WordPress ralentizan tu sitio

Cada página que sirve WordPress implica decenas, a veces cientos, de consultas a la base de datos: opciones, menús, widgets, entradas, metadatos. Si alguna de esas consultas MySQL está mal escrita o le falta un índice, el tiempo de generación de la página se dispara. Lo he visto muchas veces: webs con un TTFB (Time To First Byte) por encima de 2 segundos que, bien ajustadas, responden en menos de 400 milisegundos.

El plan aquí es doble. Medir y diagnosticar qué consultas se comen el tiempo. Y luego aplicar correcciones concretas sobre la base de datos, el código y la configuración del servidor.

Cómo medir el tiempo de generación de base de datos

Sin datos no hay optimización. Solo intuiciones. Estas son las formas más efectivas de localizar el problema.

Activar SAVEQUERIES

WordPress trae de serie una constante de depuración que registra todas las consultas ejecutadas, junto con su tiempo y el punto del código que las originó. Edita wp-config.php y añade:

• define( ‘SAVEQUERIES’, true );
• define( ‘WP_DEBUG’, true );

Después, en tu tema o en un plugin temporal, imprime los resultados:

• if ( current_user_can( ‘administrator’ ) && defined( ‘SAVEQUERIES’ ) ) {
•   echo ‘<pre>’;
•   print_r( $wpdb->queries );
•   echo ‘</pre>’;
• }

Un aviso: desactiva SAVEQUERIES en cuanto termines el análisis. Guarda cada consulta en memoria y penaliza el rendimiento de forma notable.

Usar Query Monitor

El plugin gratuito Query Monitor es, para mí, la herramienta de referencia. Añade un panel en la barra de administración donde ves el tiempo total de las consultas, las más lentas, los duplicados y los errores. Qué revisar:

• Tiempo total de base de datos: si supera el 30% del tiempo total de generación de la página, hay margen claro de mejora.
• Consultas duplicadas: delatan código mal estructurado que pide los mismos datos varias veces.
• Consultas por página: por encima de 100, señal de alerta.
• Componente responsable: Query Monitor te dice qué plugin, tema o función origina cada consulta.

Revisar el log de consultas lentas de MySQL

A nivel de servidor, activa el slow query log de MySQL para capturar consultas que tardan más de 1 segundo:

• SET GLOBAL slow_query_log = ‘ON’;
• SET GLOBAL long_query_time = 1;

En hosting compartido puede que necesites solicitarlo al proveedor o usar un plan con acceso SSH. En RedServicio (redservicio.net) puedes encontrar ayuda profesional para analizar estos logs y ajustar la configuración de tu servidor.

Causas más comunes de consultas lentas en WordPress

Tabla wp_options con autoload masivo

El problema número uno en instalaciones viejas. Las opciones marcadas con autoload = yes se cargan en cada página, todas. Si la suma supera los 800 KB o incluso 1 MB, el impacto es grave. Compruébalo:

• SELECT SUM( LENGTH( option_value ) ) FROM wp_options WHERE autoload = ‘yes’;

Y para localizar las opciones más pesadas:

• SELECT option_name, LENGTH( option_value ) AS size FROM wp_options WHERE autoload = ‘yes’ ORDER BY size DESC LIMIT 20;

Suelen ser las culpables las opciones huérfanas de plugins ya desinstalados (transients, configuraciones residuales). Identifícalas por el prefijo del plugin y elimínalas con precaución, siempre tras hacer backup.

Transients y datos transitorios caducados

La tabla wp_options acumula miles de transients caducados que MySQL debe procesar igualmente. Límpialos periódicamente:

• DELETE FROM wp_options WHERE option_name LIKE ‘\_transient\_%’;
• DELETE FROM wp_options WHERE option_name LIKE ‘\_site\_transient\_%’;

Plugins como WP-Optimize o Transients Manager automatizan esta limpieza.

Tablas gigantes: wp_postmeta y wp_actionscheduler_actions

wp_postmeta crece sin control con plugins de SEO, campos personalizados o tiendas WooCommerce. Un sitio con millones de filas necesita índices adecuados. Verifica que existan índices en meta_key y considera añadir índices compuestos para los patrones de consulta de tus plugins más pesados.

Revisiones de entradas y basura acumulada

Miles de revisiones multiplican el tamaño de wp_posts y ralentizan las búsquedas. Limita las revisiones en wp-config.php:

• define( ‘WP_POST_REVISIONS’, 5 );

Y elimina las existentes con una consulta controlada o con WP-CLI:

• wp post delete $(wp post list –post_type=revision –format=ids)

Estrategias de optimización de consultas

Añadir caché de objetos

Redis u object cache en memoria reduce drásticamente las consultas repetitivas. Con un backend persistente (Redis o Memcached), el autoload de opciones solo se consulta una vez y los resultados se sirven desde memoria en microsegundos. Para Redis en un servidor propio:

• Instalar redis-server y la extensión PHP php-redis.
• Instalar el plugin Redis Object Cache y activarlo.

No es raro ver reducciones del 40% al 60% en el tiempo de base de datos tras esta mejora.

Corregir consultas mal escritas en temas y plugins

Errores frecuentes que debes buscar en tu código:

• Usar post__not_in: genera consultas con NOT IN sobre listas enormes. Sustitúyelo por lógica en PHP o índices excluyentes.
• Consultas dentro de bucles (N+1): llamar a get_post_meta por cada entrada. Usa update_meta_cache o una única consulta con un meta_query agrupado.
• no_found_rows: si no necesitas paginación, añade ‘no_found_rows’ => true a WP_Query para evitar el cálculo de SQL_CALC_FOUND_ROWS, muy costoso.
• Campos innecesarios: usa ‘fields’ => ‘ids’ cuando solo necesites identificadores.

Mantenimiento de tablas e índices

Ejecuta periódicamente:

• OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options;
• ANALYZE TABLE wp_posts;

Con esto desfragmentas las tablas InnoDB y actualizas las estadísticas que el optimizador de MySQL usa para elegir índices.

Verificar la mejora tras optimizar

Repite las mediciones con Query Monitor y compara: tiempo total de consultas, número de consultas y TTFB. Herramientas como New Relic o el monitoreo de MySQL Workbench permiten confirmar la mejora de forma continua. Fija un umbral objetivo: un WordPress bien optimizado debe completar la generación de página con menos de 50 consultas y menos de 50 milisegundos de tiempo de base de datos.

Conclusión

El tiempo de generación de base de datos es uno de los factores con más impacto en la velocidad real de un sitio WordPress y, probablemente, el más descuidado. Con un proceso ordenado (medir con SAVEQUERIES y Query Monitor, identificar cargas autoload excesivas, limpiar transients y revisiones, añadir caché de objetos y corregir consultas ineficientes) puedes bajar el TTFB de tu web de forma drástica y sostenible. Un matiz: la optimización no es un evento único. Establece revisiones periódicas y monitorización continua, porque el rendimiento se degrada solo. Y si prefieres delegar el diagnóstico y la puesta a punto de tu base de datos, en RedServicio (redservicio.net) encontrarás ayuda profesional especializada en optimización de WordPress y servidores para que tu web vuelva a responder en milisegundos.