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 INSERToperacje 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 NUMBERSkładnia jest dość podatny na błędy.
SELECT *połączeniu z indeksem kolumny w ORDER BYpowoduje 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ś”
iddo znalezienia pierwszego wiersza. Drugi musi posortować pełny wynik wvalkolumnie (nieindeksowanej) .