Considera una tabella di valori e hash, in questo modo:
+------------+----------+------+-----+---------+----------------+
| 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 | |
+------------+----------+------+-----+---------+----------------+
La seguente query termina in 0,00 secondi:
SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;
Tuttavia, questa query richiede 3 minuti e 17 secondi:
SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;
Vedo che mentre la query è in esecuzione l'elenco dei processi lo mostra come stato Sorting result
. La situazione è completamente riproducibile. Si noti che esiste un altro processo che esegue continuamente INSERT
operazioni sulla tabella.
Perché l'esecuzione della *
query più specifica richiederebbe più tempo della query? Ho sempre creduto che le *
query dovessero essere evitate specificamente per motivi di prestazioni.
ORDER BY NUMBER
sintassi è piuttosto soggetta a errori.
SELECT *
combinato con un indice di colonna in ORDER BY
è offuscare quale colonna viene ordinata - un altro motivo per evitare *
s ...
*
non è esplicito. Quindi dire "dammi tutte le colonne e ordinare per il terzo" è deterministico quanto dire "vai al supermercato e dimmi quanti semafori hai superato"
id
per trovare la prima riga. Il secondo deve ordinare il risultato completo nellaval
colonna (non indicizzata) .