Rozważ tabelę wartości i skrótów, takie jak:
+------------+----------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+----------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| val | char(9) | NO | | NULL | |
| val_hashed | char(50) | YES | | NULL | |
+------------+----------+------+-----+---------+----------------+
Następujące zapytanie kończy się za 0,00 sekundy:
SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;
Jednak to zapytanie zajmuje 3 min 17 sekund:
SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;
Widzę, że podczas działania zapytania lista procesów pokazuje go jako status Sorting result
. Sytuacja jest całkowicie powtarzalna. Zauważ, że istnieje inny proces wykonujący INSERT
operacje na stole w sposób ciągły.
Dlaczego uruchomienie bardziej szczegółowego zapytania trwa dłużej niż *
zapytanie? Zawsze uważałem, że *
należy unikać zapytań specjalnie ze względu na wydajność.
ORDER BY NUMBER
Składnia jest dość podatny na błędy.
SELECT *
połączeniu z indeksem kolumny w ORDER BY
powoduje zaciemnienie sortowanej kolumny - kolejny powód, dla którego należy unikać *
...
*
nie jest jednoznaczne. Zatem powiedzenie „daj mi wszystkie kolumny i posortuj według trzeciego” jest tak samo deterministyczne jak powiedzenie „idź do supermarketu i powiedz, ile świateł minąłeś”
id
do znalezienia pierwszego wiersza. Drugi musi posortować pełny wynik wval
kolumnie (nieindeksowanej) .