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 INSERToperazioni 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 NUMBERsintassi è 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"
idper trovare la prima riga. Il secondo deve ordinare il risultato completo nellavalcolonna (non indicizzata) .