Guía para decidir mejor
Cómo detectar consultas lentas y consumo alto de MySQL en WordPress
Relaciona una consulta costosa con su ruta y carga antes de tocar índices o servidor.
Una consulta lenta en WordPress no siempre significa que MySQL o MariaDB necesite más memoria. Puede faltar un índice, sobrar una consulta repetida de un plugin, existir un bloqueo entre transacciones o haber demasiadas peticiones simultáneas. Para diagnosticar el consumo alto de la base, relaciona consulta, página, carga y hora antes de optimizar tablas o cambiar de plan.
Comprueba primero el patrón de lentitud
Separa páginas públicas cacheadas, rutas dinámicas, administración, búsqueda y checkout. Registra hora, URL, duración, TTFB y número de solicitudes concurrentes. Si solo tarda una página con un filtro complejo, busca las consultas de esa ruta; si todo se ralentiza en una campaña, observa conexiones y CPU de la base. Las llamadas externas y PHP también pueden retrasar una respuesta sin que SQL sea la causa. Revisa el diagnóstico general de WordPress lento para no saltar de una métrica a una conclusión.
Identifica consultas y bloqueos con acceso autorizado
En staging, un perfilador compatible puede mostrar consulta, origen y tiempo por petición. En producción, el administrador puede habilitar durante una ventana limitada el registro de consultas lentas o las métricas equivalentes de MariaDB/MySQL, con control de acceso y retención. El manual de MySQL sobre slow query log explica que registra sentencias que superan un umbral definido; una consulta ausente no demuestra que la base esté sana si el umbral o la captura no cubren el incidente. No publiques SQL con emails, tokens o datos de clientes.
Para una consulta repetida, observa frecuencia y suma de tiempo, no solo el peor caso. Usa EXPLAIN con un técnico antes de añadir índices; los índices cambian escrituras y espacio. Si hay bloqueos, identifica transacciones largas o tareas simultáneas. Si MySQL consume mucha CPU pero las consultas son rápidas, revisa volumen, conexiones, operaciones de mantenimiento y otras aplicaciones que comparten el servidor. No ejecutes OPTIMIZE TABLE en plena campaña como respuesta automática.
Corrige la causa verificable
Ejemplo hipotético: el catálogo tarda solo al filtrar miles de productos, y un plugin emite la misma consulta costosa por cada variación. Primero prueba una versión corregida, otro diseño de filtro o un índice respaldado por pruebas; ampliar RAM sin cambiar el patrón quizá no baste. Otro escenario: durante copias y sincronizaciones coinciden picos de I/O con consultas normales; redistribuir tareas puede ser más útil que tocar SQL.
Antes de intervenir, guarda copia recuperable y prueba en un conjunto representativo. Después compara la misma ruta, tamaño de datos y carga, y verifica pedidos, informes y búsquedas. La guía limpieza segura de datos explica cuándo reducir filas obsoletas; no sustituye al análisis de consultas. Si debes discutir capacidad, envía métricas y un extracto saneado, nunca credenciales de base.