Les index n'améliorent pas nécessairement les performances. Pour mieux comprendre ce qui se passe, il serait utile d'inclure le explain pour les différentes requêtes.
Ma meilleure supposition serait que vous avez un index dans id_state ou même id_state, id_mp qui peut être utilisé pour satisfaire le where clause. Si oui, la première requête sans le order by utiliserait cet indice. Cela devrait être assez rapide. Même sans index, cela nécessite un balayage séquentiel des pages dans les orders table, qui peut encore être assez rapide.
Ensuite, lorsque vous ajoutez l'index le creation_date , MySQL décide d'utiliser cet index à la place pour le order by . Cela nécessite de lire chaque ligne de l'index, puis de récupérer la page de données correspondante pour vérifier where conditions et renvoie les colonnes (s'il y a une correspondance). Cette lecture est très inefficace, car elle n'est pas dans l'ordre des "pages" mais plutôt comme spécifié par l'index. Les lectures aléatoires peuvent être assez inefficaces.
Pire, même si vous avez une limit , vous devez encore lire l'intégralité table car le jeu de résultats complet est nécessaire. Bien que vous ayez enregistré un tri sur 38 enregistrements, vous avez créé une requête massivement inefficace.
Soit dit en passant, cette situation s'aggrave considérablement si les orders la table ne tient pas dans la mémoire disponible. Ensuite, vous avez une condition appelée "thrashing", où chaque nouvel enregistrement a tendance à générer une nouvelle lecture d'E/S. Ainsi, si une page contient 100 enregistrements, la page peut devoir être lue 100 fois.
Vous pouvez accélérer l'exécution de toutes ces requêtes en ayant un index sur orders(id_state, id_mp, creation_date) . Le where la clause utilisera les deux premières colonnes et le order by utilisera le dernier.
