Indekser forbedrer ikke nødvendigvis ydeevnen. For bedre at forstå, hvad der sker, ville det hjælpe, hvis du inkluderede explain for de forskellige forespørgsler.
Mit bedste gæt ville være, at du har et indeks i id_state eller endda id_state, id_mp der kan bruges til at tilfredsstille where klausul. Hvis ja, den første forespørgsel uden orden efter ville bruge dette indeks. Det burde være ret hurtigt. Selv uden et indeks kræver dette en sekventiel scanning af siderne i ordrerne tabel, hvilket stadig kan være ret hurtigt.
Så når du tilføjer indekset på creation_date , beslutter MySQL at bruge det indeks i stedet for orden efter . Dette kræver, at hver række i indekset læses, og derefter hentes den tilsvarende dataside for at kontrollere hvor betingelser og returnere kolonnerne (hvis der er et match). Denne læsning er meget ineffektiv, fordi den ikke er i "side"-rækkefølge, men snarere som angivet af indekset. Tilfældige læsninger kan være ret ineffektive.
Værre, selvom du har en grænse , du skal stadig læse hele tabel, fordi hele resultatsættet er nødvendigt. Selvom du har gemt en sortering på 38 poster, har du skabt en massivt ineffektiv forespørgsel.
Forresten bliver denne situation væsentligt værre, hvis ordrer tabellen passer ikke i tilgængelig hukommelse. Så har du en tilstand kaldet "thrashing", hvor hver ny post har en tendens til at generere en ny I/O-læsning. Så hvis en side har 100 poster på den, skal siden muligvis læses 100 gange.
Du kan få alle disse forespørgsler til at køre hurtigere ved at have et indeks på orders(id_state, id_mp, creation_date) . orden efter vil bruge den sidste.