Una consulta SQL lenta no se resuelve de forma sostenible “añadiendo un índice” hasta saber qué petición la ejecuta, con qué frecuencia y si la base de datos es realmente la parte dominante del tiempo. Mide forma de query, frecuencia y filas examinadas juntas.
Relaciona la query con una petición
Usa tracing, Query Monitor en entorno seguro, slow log o APM para identificar página, REST, cron o acción admin que la dispara.
Mide frecuencia además de duración
Una query de 400 ms una vez por hora y una de 40 ms repetida 200 veces por request tienen prioridades distintas. Cuenta ejecuciones y concurrencia.
Inspecciona el plan de ejecución
Revisa índices usados, filas examinadas, temporales, sorts y joins con parámetros realistas. No añadas índices solapados solo porque una columna esté en WHERE.
Reduce trabajo innecesario en la aplicación
Corrige N+1, metadatos repetidos, queries sin límite y datos que el caller no usa. El tuning de base no compensa indefinidamente un patrón derrochador.
Prueba cambios con datos representativos
Una base de staging pequeña puede ocultar problemas de cardinalidad. Usa volúmenes seguros pero parecidos a producción y compara plan y latencia.
Verifica la petición completa
Confirma que mejoran tiempo total, carga de DB y errores bajo concurrencia representativa. Una query más rápida que empeora escrituras o locks puede ser una regresión.
Correlaciona tiempo de base con tracing de PHP-FPM y compara con el diagnóstico de primer byte lento antes de culpar solo a SQL.