Tak to się dzieje. Wytrzymaj ze mną chwilę...
Optymalizator chciałby użyć INDEKSU, w tym przypadku ACTI_DATE_I. Ale nie chce go używać, jeśli byłoby to wolniejsze.
Plan A:Użyj indeksu.
- Sięgnij na końcu do indeksu o strukturze BTree (ze względu na DESC)
- Skanuj wstecz
- Dla każdego wiersza w indeksie wyszukaj odpowiedni wiersz w danych. Uwaga:indeks ma (ACTIVITY_DATE, ACTIVITY_ID), ponieważ klucz podstawowy jest niejawnie dołączony do dowolnego klucza pomocniczego. Sięgnięcie do „danych” za pomocą PK (ACTIVITY_ID) jest kolejnym wyszukiwaniem BTree, potencjalnie losowym. Dlatego jest potencjalnie powolny. (Ale w twoim przypadku niezbyt powolny).
- Zatrzymuje się po LIMIT wierszach.
Plan B:zignoruj tabelę
- Skanuj tabelę, tworząc tabelę tmp. (Prawdopodobnie w pamięci.)
- Posortuj tabelę tmp
- Odklej LIMIT wierszy.
W twoim przypadku (96 -- 1% z 10K) zaskakujące jest to, że wybrał skan tabeli. Zwykle odcięcie wynosi około 10%-30% liczby wierszy w tabeli.
ANALYZE TABLE powinien spowodowały ponowne obliczenie statystyk, co mogło przekonałem go, by pasował do drugiego planu.
Jakiej wersji MySQL używasz? (Nie, nie znam żadnych zmian w tym obszarze.)
Jedna rzecz, którą możesz spróbować:OPTIMIZE TABLE ACTIVITIES; To odbuduje tabelę, tym samym przepakowując bloki i prowadząc do potencjalnie różne statystyki. Jeśli to pomoże, chciałbym o tym wiedzieć — ponieważ zwykle mówię, że „Tabela optymalizacji jest bezużyteczna”.
