Indizes verbessern nicht unbedingt die Leistung. Um besser zu verstehen, was passiert, wäre es hilfreich, wenn Sie explain einfügen würden für die verschiedenen Abfragen.
Meine beste Vermutung wäre, dass Sie einen Index in id_state haben oder sogar id_state, id_mp das verwendet werden kann, um das where zu erfüllen Klausel. Wenn ja, die erste Abfrage ohne den order by würde diesen Index verwenden. Es sollte ziemlich schnell gehen. Auch ohne Index erfordert dies ein sequentielles Scannen der Seiten in den orders Tabelle, die immer noch ziemlich schnell sein kann.
Dann, wenn Sie den Index am creation_date hinzufügen , entscheidet sich MySQL dafür, diesen Index stattdessen für die order by zu verwenden . Dazu muss jede Zeile im Index gelesen und dann die entsprechende Datenseite abgerufen werden, um das where zu überprüfen Bedingungen und geben die Spalten zurück (falls es eine Übereinstimmung gibt). Dieses Lesen ist höchst ineffizient, weil es nicht in der "Seiten"-Reihenfolge erfolgt, sondern wie durch den Index angegeben. Zufällige Lesevorgänge können ziemlich ineffizient sein.
Schlimmer noch, obwohl Sie ein limit haben , müssen Sie noch ganz lesen Tabelle, da die gesamte Ergebnismenge benötigt wird. Obwohl Sie eine Sortierung von 38 Datensätzen gespeichert haben, haben Sie eine massiv ineffiziente Abfrage erstellt.
Übrigens wird diese Situation deutlich schlimmer, wenn der orders Tabelle passt nicht in den verfügbaren Speicher. Dann haben Sie eine Bedingung namens "Thrashing", bei der jeder neue Datensatz dazu neigt, einen neuen I/O-Lesevorgang zu generieren. Wenn also eine Seite 100 Datensätze enthält, muss die Seite möglicherweise 100 Mal gelesen werden.
Sie können all diese Abfragen beschleunigen, indem Sie einen Index für orders(id_state, id_mp, creation_date) haben . Das where -Klausel verwendet die ersten beiden Spalten und den order by wird die letzte verwenden.
