Indexy nutně nezlepšují výkon. Abyste lépe porozuměli tomu, co se děje, pomohlo by, kdyby jste zahrnuli explain pro různé dotazy.
Můj nejlepší odhad by byl, že máte index v id_state nebo dokonce id_state, id_mp které lze použít k uspokojení where doložka. Pokud ano, první dotaz bez order by by použil tento index. Mělo by to být docela rychlé. I bez indexu to vyžaduje sekvenční skenování stránek v orders stůl, což může být stále docela rychlé.
Poté, když přidáte index na creation_date , MySQL se rozhodne použít tento index místo toho pro order by . To vyžaduje přečtení každého řádku v indexu a následné načtení odpovídající datové stránky a zkontrolování where podmínky a vrátit sloupce (pokud existuje shoda). Toto čtení je vysoce neefektivní, protože není v pořadí „stránek“, ale spíše podle indexu. Náhodné čtení může být docela neefektivní.
Horší, i když máte limit , stále si musíte přečíst celý tabulky, protože je potřeba celá sada výsledků. Přestože jste uložili řazení na 38 záznamech, vytvořili jste značně neefektivní dotaz.
Mimochodem, tato situace se výrazně zhorší, pokud orders tabulka se nevejde do dostupné paměti. Pak máte stav zvaný "thrashing", kde každý nový záznam má tendenci generovat nové I/O čtení. Pokud tedy stránka obsahuje 100 záznamů, může být nutné stránku přečíst 100krát.
Všechny tyto dotazy můžete zrychlit tím, že budete mít index na orders(id_state, id_mp, creation_date) . where klauzule použije první dva sloupce a order by použije poslední.