Duża ilość Handler_read_rnd oraz Handler_read_rnd_next, Czy pola w klauzuli ORDER BY powinny być indexowane? Opcje

[Athlan]

Witam.

Jak wiemy, każdy potrafi napisać duży portal, ale mało kto potrafi go poprawnie zaprojektować. Ciężko się przyznać, ale zdarzyła się niespodziewana rzecz. Serwer bazy mysql nie wyrabia. W stanie serwera w phpmyadmin otrzymałem takie oto 2 liczby na czerwono:

Handler_read_rnd
23 k
Liczba żądań odczytu następnego rekordu na podstawie stałego położenia. Wartość jest duża przy wykonywaniu dużej ilości zapytań wymagających sortowania rezultatu. Prawdopodobnie wykonano wiele zapytań wymagających przeszukania całej tabeli lub złączeń, które nie używają poprawnie indeksów.

oraz

Handler_read_rnd_next
17 M
Liczba żądań odczytu następnego rekord w pliku z danymi. Wartość jest duża przy wykonywania wielu przeszukiwań tabeli. Ogólnie sugeruje to, że tabele nie są poprawnie zindeksowane lub że zapytania nie są napisane w sposób pozwalający skorzystać z istniejących indeksów.

I to przez jedyne 6 godzin pracy serwera bazy danych. Jak zobaczyłem drugą liczbę, to oczy mi wyszły z orbit. Wiadomo, niepoprawne indexy, czyli rozwiązaniem jest explain każdego pojedynczego zapytania i praktycznie 25% kluczy do wymiany/dodania.

Natomiast dziwi mnie pierwsza wartość. Wiadomo, że często używa się ORDER BY. I tutaj bardzo ważne pytanie: czy pola w klauzuli ORDER powinny być indexowane?

Na zdrowy rozsądek tak, bo nie trzeba będzie pobierać tych pól z tabeli, jakby nie patrzeć całą ją skanując (nie znamy wartości pól). Czy może indexowanie jest niepotrzebne?

Z góry dzięki za odpowiedzi.

[batman]

Nie wiem dokładnie jest to jest w mysql, ale całe komputerowe życiue byłem uczony, by zakładać indexy na kolumny, na których najczęściej wykonywane są operacje. Czyli wyszukiwanie, czy sortowanie. Podczas projektowania dużej aplikacji, zawsze zakładam indeks na kolumnę, po której najczęściej będzie odbywać się sortowanie. Nigdy nie miałem problemów z wydajnością bazy danych.
Nie należy jednak popadać ze skrajności w skrajność. Im więcej indeksów na tabeli, tym bardziej odwrotny efekt zostanie osiągnięty. Zamiast przyspieszyć, wszystko zwolni.