Una consulta SQL lenta no es resol de manera sostenible “afegint un índex” fins que saps quina petició l’executa, amb quina freqüència i si la base de dades és realment la part dominant del temps. Mesura forma de query, freqüència i files examinades juntes.
Relaciona la query amb una petició
Usa tracing, Query Monitor en entorn segur, slow log o APM per identificar pàgina, REST, cron o acció admin que la dispara.
Mesura freqüència a més de durada
Una query de 400 ms una vegada per hora i una de 40 ms repetida 200 vegades per request tenen prioritats diferents. Compta execucions i concurrència.
Inspecciona el pla d’execució
Revisa índexs usats, files examinades, temporals, sorts i joins amb paràmetres realistes. No afegeixis índexs solapats només perquè una columna aparegui al WHERE.
Redueix feina innecessària a l’aplicació
Corregeix N+1, metadades repetides, queries sense límit i dades que el caller no usa. El tuning de base no compensa indefinidament un patró malbaratador.
Prova canvis amb dades representatives
Una base de staging petita pot ocultar problemes de cardinalitat. Usa volums segurs però semblants a producció i compara pla i latència.
Verifica la petició completa
Confirma que milloren temps total, càrrega de DB i errors sota concurrència representativa. Una query més ràpida que empitjora escriptures o locks pot ser una regressió.
Correlaciona temps de base amb tracing de PHP-FPM i compara amb el diagnòstic de primer byte lent abans de culpar només SQL.