
Las consultas lentas MySQL están detrás de buena parte de los problemas de rendimiento en WordPress y, en general, en cualquier aplicación web dinámica. Cuando una consulta tarda varios segundos en ejecutarse, la web se arrastra, el servidor consume recursos de más y, en máquinas compartidas, los cuellos de botella acaban pasando factura a otros sitios alojados en el mismo servidor. La buena noticia: MySQL y MariaDB traen de serie una herramienta para cazarlas. Se llama slow query log. En esta guía verás cómo activarla, configurarla y analizar su salida con mysqldumpslow y pt-query-digest.
Qué es el slow query log y por qué necesitas activarlo
El slow query log es un registro que MySQL escribe en disco cada vez que una consulta supera un umbral de tiempo de ejecución definido por el administrador. Por defecto viene desactivado. Y eso tiene una consecuencia incómoda: la mayoría de servidores funcionan a ciegas, con consultas problemáticas ejecutándose sin dejar rastro alguno.
¿Qué ganas al activarlo? Tres cosas, básicamente:
- Diagnóstico preciso: sabes exactamente qué consultas son lentas, cuándo corren y cuánto tardan.
- Detección de patrones: al revisar el log descubres consultas repetidas, tablas sin índices o plugins de WordPress que generan peticiones ineficientes.
- Punto de partida para optimizar: sin datos no hay optimización posible. El log es la base sobre la que trabajar con EXPLAIN, índices y reescritura de consultas.
Consejo: si gestionas WordPress, presta especial atención a las consultas sobre las tablas wp_options y wp_postmeta. Son las que más aparecen en los logs de servidores con carga alta.
Cómo activar el slow query log en MySQL y MariaDB
Puedes activarlo de dos formas: temporal (sin reiniciar el servicio) o permanente (editando la configuración). Para activarlo en caliente, conéctate al servidor y ejecuta:
- Accede al cliente MySQL: mysql -u root -p
- Activa el log y define el umbral en segundos:
SET GLOBAL slow_query_log = ‘ON’;
SET GLOBAL slow_query_log_file = ‘/var/log/mysql/slow.log’;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = ‘ON’;
Con long_query_time = 1 registrarás toda consulta que tarde más de un segundo. Un punto de partida razonable. Si lo quieres permanente (y lo querrás), añade esto al fichero de configuración, normalmente /etc/mysql/my.cnf o /etc/my.cnf según la distribución:
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1
Después reinicia el servicio con systemctl restart mysql y verifica con SHOW VARIABLES LIKE ‘slow_query%’; que todo se ha aplicado bien.
Importante: comprueba que el directorio del log existe y que el usuario mysql tiene permisos de escritura. Un log inaccesible hace que la activación falle en silencio, y eso desespera.
Cómo analizar consultas lentas MySQL con mysqldumpslow y pt-query-digest
El log en bruto es difícil de digerir, sobre todo en servidores con tráfico. Aquí es donde entran las herramientas de análisis.
mysqldumpslow viene incluido con MySQL y agrupa consultas similares resumiendo los valores literales. Uso habitual:
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
Ese comando muestra las 10 consultas que más tiempo total han consumido. Otras opciones que conviene conocer:
- -s c: ordena por número de ejecuciones (útil para detectar consultas repetidas).
- -s r: ordena por filas devueltas.
- -g: filtra por patrón, por ejemplo -g «wp_postmeta».
pt-query-digest, de Percona Toolkit, es la opción más potente con diferencia. Genera un informe detallado con percentiles, distribución de tiempos y ejemplos de cada consulta:
pt-query-digest /var/log/mysql/slow.log > informe.txt
El informe se ordena por impacto global, y eso permite priorizar con cabeza. Un matiz que mucha gente pasa por alto: no siempre la consulta más lenta en sí es la más problemática. A veces lo es la que se repite mil veces por minuto.
Con el log activo y estas herramientas a mano, ya tienes el sistema de diagnóstico funcionando. En las siguientes partes de la guía veremos cómo interpretar los resultados con EXPLAIN y cómo corregir las causas más frecuentes.
Optimización de consultas: índices, EXPLAIN y buenas prácticas
Localizadas las consultas problemáticas, toca arreglarlas. Y aquí la herramienta clave es EXPLAIN: te enseña cómo MySQL ejecuta realmente una consulta. Qué índices usa, cuántas filas examina, qué tipo de join aplica. Sin esto vas a ciegas.
El manejo es sencillo. De verdad:
- Copia la consulta problemática del slow query log.
- Ejecuta EXPLAIN SELECT … delante de la consulta.
- Analiza las columnas type, key y rows.
¿Y qué mirar exactamente? Si en type aparece ALL, mala noticia: MySQL está recorriendo la tabla entera (full table scan). Es la señal más clara de que falta un índice. Lo mismo si key sale como NULL, porque entonces ninguna indexación se está aprovechando.
Un ejemplo. Imagina que esta consulta aparece sin parar en tu log:
SELECT * FROM pedidos WHERE cliente_id = 452 AND estado = ‘pendiente’;
Si no existe un índice compuesto, lo creas así:
CREATE INDEX idx_cliente_estado ON pedidos (cliente_id, estado);
Y sí, funciona. Un índice compuesto por las columnas del WHERE suele bajar el tiempo de ejecución de segundos a milisegundos. He visto consultas que «de repente» vuelan y casi siempre hay un índice así detrás.
Buenas prácticas adicionales
- Evita SELECT *: selecciona solo las columnas necesarias para permitir covering indexes.
- No uses funciones sobre columnas indexadas: WHERE YEAR(fecha) = 2024 anula el índice; usa rangos en su lugar.
- Cuidado con LIKE ‘%texto’: el comodín inicial impide usar índices B-tree.
- Revisa los tipos de datos: comparar un INT con un VARCHAR puede forzar conversiones implícitas que rompen la indexación.
- Limita los resultados: usa LIMIT cuando no necesites todo el conjunto.
Eso sí, no te confíes. Después de cada cambio, vuelve a ejecutar EXPLAIN y comprueba que el plan de ejecución ha mejorado y que el optimizador realmente usa el índice nuevo.
Errores comunes al interpretar el slow query log
El slow query log es potente, pero también da pie a interpretaciones equivocadas. He visto fallar a mucha gente por lo mismo, una y otra vez:
- Fijarse solo en el tiempo individual: una consulta de 0,8 segundos que se ejecuta 5.000 veces por hora es más grave que una de 10 segundos que corre una vez al día. Observa la frecuencia, no solo la duración.
- Ignorar Rows_examined: si una consulta devuelve 10 filas pero examina 500.000, hay un problema de índices evidente, aunque tarde poco.
- Olvidar que pt-query-digest normaliza consultas: los literales se sustituyen por placeholders. No busques el valor exacto en la base de datos, busca el patrón de la consulta.
- Añadir índices sin medir: cada índice ralentiza INSERT, UPDATE y DELETE, y ocupa espacio. Créalos a partir de datos del log, no por intuición.
- Dejar el log con long_query_time muy bajo en producción: puede generar I/O excesivo y llenarte el disco. Ajusta el umbral según tu carga real.
- Optimizar sin una copia de prueba: valida siempre los cambios en un entorno de staging con datos representativos antes de aplicarlos en producción. Siempre.
Esquivar estos errores te ahorrará sesiones de optimización infructuosas y, sobre todo, cambios que acaban empeorando el rendimiento general del servidor.
Conclusión: monitoriza y optimiza tus consultas lentas MySQL
Las consultas lentas MySQL no son un problema puntual que se arregla y se olvida. Es un proceso continuo de monitorización y mejora. Activar el slow query log con los parámetros adecuados, analizarlo periódicamente con herramientas como pt-query-digest o mysqldumpslow y corregir las causas con índices bien diseñados y EXPLAIN como guía: ese es el flujo de trabajo que mantiene una base de datos sana a medida que crece el tráfico.
¿Los pilares? Un umbral de long_query_time realista, atención a la frecuencia y a las filas examinadas, índices compuestos basados en tus patrones de consulta reales y validación de cada cambio con un plan de ejecución mejorado. La optimización no termina nunca. Pero con este sistema instalado detectarás los problemas antes de que afecten a tus usuarios, y eso cambia mucho la experiencia.
Si tu servidor WordPress o tu aplicación sigue mostrando lentitud tras aplicar estas medidas, o si prefieres que un especialista audite tu base de datos y tu configuración MySQL, en RedServicio (redservicio.net) encontrarás ayuda profesional para diagnosticar y resolver cualquier problema de rendimiento en tu hosting.

