Problemet er, at MySQL kun bruger ét indeks, når forespørgslen udføres. Hvis du tilføjer et nyt indeks, der bruger de 3 felter i din WHERE klausul, vil den finde rækkerne hurtigere.
ALTER TABLE `adverts` ADD INDEX price_status_approved(`price`, `status`, `approved`);
Ifølge MySQL-dokumentationen ORDER BY Optimization :
Dette er, hvad der sker i dit tilfælde. Som output fra EXPLAIN fortæller os, at optimeringsværktøjet bruger nøglen price for at finde rækkerne. Men ORDER BY er i feltet date_updated som ikke hører til nøglen price .
For at finde rækkerne hurtigere OG sortere rækkerne hurtigere, skal du tilføje et indeks, der indeholder alle de felter, der bruges i WHERE og i ORDER BY klausuler:
ALTER TABLE `adverts` ADD INDEX status_approved_date_updated(`status`, `approved`, `date_updated`);
Feltet, der bruges til sortering, skal være på den sidste position i indekset. Det er nytteløst at inkludere price i indekset, fordi betingelsen, der bruges i forespørgslen, vil returnere en række værdier.
Hvis EXPLAIN stadig viser, at den bruger filesort, kan du prøve at tvinge MySQL til at bruge et indeks, du vælger:
SELECT adverts.*
FROM adverts
FORCE INDEX(status_approved_date_updated)
WHERE price >= 0
AND adverts.status = 1
AND adverts.approved = 1
ORDER BY date_updated DESC
LIMIT 19990, 10
Det er normalt ikke nødvendigt at fremtvinge et indeks, fordi MySQL optimizeren oftest gør det rigtige valg. Men nogle gange gør det et dårligt valg, eller ikke det bedste valg. Du bliver nødt til at køre nogle test for at se, om det forbedrer ydeevnen eller ej.