MySQL select wydaje się bardzo powolny, ale nie możesz pomyśleć, jak to ulepszyć?

Myślę, że są pewne problemy z zapytaniem i samą definicją tabeli.

• Table.name to kolumna znaków 4K
• Zapytanie jest sortowane według tej kolumny

Sortujesz na podstawie kolumny, w której przechowujesz ciągi. Aby posortować według ciągów, należy wykonać porównania ciągów. Porównanie ciągów jest zwykle powolną operacją, a biorąc pod uwagę rozmiar używanej kolumny, najprawdopodobniej spowoduje zauważalny spadek wydajności.

Nie mamy informacji o zawartości Twojego name i wydaje się, że trudno wymyślić nazwę, która wymagałaby tego wiele znaków.

Jeśli ten ciąg zawiera kilka fragmentów danych, które są koncepcyjnie różne, być może kolumna powinna zostać podzielona na wiele oddzielnych kolumn, jeśli to możliwe, a następnie odpowiednio znormalizowana.

Jeśli możesz podzielić zawartość tej kolumny na wiele mniejszych, a następnie ich użyć, porównania ciągów, chociaż nadal drogie, będą „szybsze”, ponieważ porównywane ciągi będą znacznie krótsze niż teraz.

Inną rzeczą do rozważenia jest to, czy możesz zoptymalizować wyszukiwanie, unikając porównywanie ciągów w ogóle lub unikanie zapytań, które spowodują pełne skanowanie tabeli, pomimo tego, że zdefiniowałeś indeksy.

W tym celu powinieneś spojrzeć na użycie explain z zapytaniem, aby lepiej zrozumieć Plan wykonania zapytania

Cytując dokumenty (moje podkreślenie):

Edytuj 1

Wyjaśniłeś, że Twoje name kolumna jest faktycznie dla notatek użytkownika. W takim przypadku uważam, że powinieneś rozważyć następujące (dodatkowo dodatkowe do tego, co już zostało wspomniane):

1. Zmień nazwę kolumny na coś, co odpowiada jej rzeczywistej zawartości
2. Usuń indeks z kolumny
3. Nie nie użyj tej kolumny do wyszukiwania, sortowania lub dowolnej innej operacji poza zaznaczaniem jej w celu wyświetlenia (byłoby to bardzo rzadkie, jeśli musiało być używane do czegokolwiek innego, IMHO.)
4. Opcjonalnie rozważ zmianę kolumny na text wpisz i nie będziesz musiał się tak bardzo martwić o eseje użytkowników zostanie obcięty bez ostrzeżenia (chyba że GUI narzucił użytkownikowi ten sam limit długości danych wejściowych)