Considere uma tabela de valores e hashes, assim:
+------------+----------+------+-----+---------+----------------+
| 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 | |
+------------+----------+------+-----+---------+----------------+
A consulta a seguir termina em 0,00 segundos:
SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;
No entanto, esta consulta leva 3 minutos e 17 segundos:
SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;
Vejo que, enquanto a consulta está sendo executada, a lista de processos a mostra como status Sorting result. A situação é completamente reproduzível. Observe que há outro processo executando INSERToperações na tabela continuamente.
Por que a consulta mais específica levaria mais tempo para ser executada do que a *consulta? Sempre acreditei que as *consultas deveriam ser evitadas especificamente por razões de desempenho.
ORDER BY NUMBERsintaxe é propensa a erros.
SELECT *combinado com um índice de coluna em, ORDER BYestá ofuscando qual coluna está sendo classificada - outro motivo para evitar *s ...
*não é explícito. Dizer "me dê todas as colunas e classifique pela terceira" é tão determinístico quanto dizer "vá ao supermercado e me diga quantos semáforos você passou"
idpara encontrar a primeira linha. O segundo precisa classificar o resultado completo navalcoluna (não indexada) .