Problemet är att MySQL bara använder ett index när frågan körs. Om du lägger till ett nytt index som använder de 3 fälten i din WHERE klausul, kommer den att hitta raderna snabbare.
ALTER TABLE `adverts` ADD INDEX price_status_approved(`price`, `status`, `approved`);
Enligt MySQL-dokumentationen ORDER BY Optimization :
Detta är vad som händer i ditt fall. Som utdata från EXPLAIN berättar att optimeraren använder nyckeln price för att hitta raderna. Men ORDER BY finns i fältet date_updated som inte tillhör nyckeln price .
För att hitta raderna snabbare OCH sortera raderna snabbare måste du lägga till ett index som innehåller alla fält som används i WHERE och i ORDER BY klausuler:
ALTER TABLE `adverts` ADD INDEX status_approved_date_updated(`status`, `approved`, `date_updated`);
Fältet som används för sortering måste vara på den sista positionen i indexet. Det är värdelöst att inkludera price i indexet, eftersom villkoret som används i frågan kommer att returnera ett värdeintervall.
Om EXPLAIN visar fortfarande att den använder filsortering, du kan försöka tvinga MySQL att använda ett index du väljer:
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 är vanligtvis inte nödvändigt att tvinga fram ett index, eftersom MySQL-optimeraren oftast gör rätt val. Men ibland gör den ett dåligt val, eller inte det bästa valet. Du måste köra några tester för att se om det förbättrar prestandan eller inte.