Indeksy niekoniecznie poprawiają wydajność. Aby lepiej zrozumieć, co się dzieje, pomocne byłoby dodanie explain dla różnych zapytań.
Domyślam się, że masz indeks w id_state lub nawet id_state, id_mp które mogą być użyte do spełnienia where klauzula. Jeśli tak, pierwsze zapytanie bez order by użyje tego indeksu. Powinno być dość szybkie. Nawet bez indeksu wymaga to sekwencyjnego skanowania stron w orders stół, który nadal może być dość szybki.
Następnie po dodaniu indeksu creation_date , MySQL decyduje się użyć tego indeksu zamiast order by . Wymaga to odczytania każdego wiersza w indeksie, a następnie pobrania odpowiedniej strony danych w celu sprawdzenia where warunki i zwróć kolumny (jeśli istnieje dopasowanie). Ten odczyt jest wysoce nieefektywny, ponieważ nie jest ułożony w kolejności „stron”, ale raczej zgodnie z indeksem. Odczyty losowe mogą być dość nieefektywne.
Gorzej, nawet jeśli masz limit , nadal musisz przeczytać całość tabeli, ponieważ potrzebny jest cały zestaw wyników. Chociaż zapisałeś sortowanie na 38 rekordach, utworzyłeś bardzo nieefektywne zapytanie.
Nawiasem mówiąc, sytuacja znacznie się pogarsza, jeśli orders tabela nie mieści się w dostępnej pamięci. Następnie masz warunek o nazwie „thrashing”, w którym każdy nowy rekord ma tendencję do generowania nowego odczytu we/wy. Tak więc, jeśli strona zawiera 100 rekordów, może być konieczne przeczytanie strony 100 razy.
Możesz przyspieszyć działanie wszystkich tych zapytań, mając indeks orders(id_state, id_mp, creation_date) . where klauzula użyje pierwszych dwóch kolumn i order by użyje ostatniego.
