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 INSERT
operaçõ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 NUMBER
sintaxe é propensa a erros.
SELECT *
combinado com um índice de coluna em, ORDER BY
está 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"
id
para encontrar a primeira linha. O segundo precisa classificar o resultado completo naval
coluna (não indexada) .