Indexen verbeteren niet noodzakelijkerwijs de prestaties. Om beter te begrijpen wat er gebeurt, zou het helpen als u de explain . opneemt voor de verschillende vragen.
Mijn beste gok zou zijn dat je een index hebt in id_state of zelfs id_state, id_mp die kan worden gebruikt om te voldoen aan de where clausule. Zo ja, de eerste zoekopdracht zonder de order by zou deze index gebruiken. Het zou behoorlijk snel moeten zijn. Zelfs zonder een index vereist dit een sequentiële scan van de pagina's in de orders tafel, wat nog steeds behoorlijk snel kan zijn.
Wanneer u vervolgens de index toevoegt op creation_date , MySQL besluit in plaats daarvan die index te gebruiken voor de order by . Hiervoor moet elke rij in de index worden gelezen en vervolgens de bijbehorende gegevenspagina worden opgehaald om de where . te controleren voorwaarden en retourneer de kolommen (als er een overeenkomst is). Deze lezing is zeer inefficiënt, omdat het niet in "pagina"-volgorde is, maar eerder zoals gespecificeerd door de index. Willekeurig lezen kan behoorlijk inefficiënt zijn.
Erger nog, ook al heb je een limit , moet je nog steeds de hele . lezen tabel omdat de volledige resultatenset nodig is. Hoewel je een sortering op 38 records hebt opgeslagen, heb je een enorm inefficiënte query gemaakt.
Trouwens, deze situatie wordt aanzienlijk erger als de orders tabel past niet in het beschikbare geheugen. Dan heb je een toestand die "thrashing" wordt genoemd, waarbij elke nieuwe record de neiging heeft om een nieuwe I/O-lezing te genereren. Dus als een pagina 100 records bevat, moet de pagina mogelijk 100 keer worden gelezen.
U kunt al deze zoekopdrachten sneller laten verlopen door een index te hebben op orders(id_state, id_mp, creation_date) . De where clausule gebruikt de eerste twee kolommen en de order by zal de laatste gebruiken.