Pourquoi SELECT * serait-il plus rapide que SELECT foo?

Considérons un tableau de valeurs et de hachages, comme ceci:

+------------+----------+------+-----+---------+----------------+
| 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 requête suivante se termine en 0,00 secondes:

SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;

Cependant, cette requête prend 3 min 17 secondes:

SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;

Je vois que pendant que la requête est en cours d'exécution, la liste des processus l'affiche comme état Sorting result. La situation est parfaitement reproductible. Notez qu'un autre processus effectue des INSERTopérations sur la table en continu.

Pourquoi la requête plus spécifique prendrait-elle plus de temps à s'exécuter que la *requête? J'ai toujours pensé que les *requêtes devaient être évitées spécifiquement pour des raisons de performances.

La phrase ORDER BY 1fait référence à différentes colonnes; dans le premier, ce sera iddans le second val. Puisque idc'est la clé, elle sera indexée etorder by sera une quantité de travail insignifiante. Pour order by val, cependant, le système devra récupérer chaque ligne, trier le tableau complet par val, puis choisir une seule de ces lignes.

Changez les deux requêtes en order by idet je pense que vos temps d'exécution seront presque identiques.

La différence de performances dans votre requête est bien expliquée par MG. Je vais aborder ceci:

J'ai toujours pensé que les requêtes * devaient être évitées spécifiquement pour des raisons de performances.

select *ne comporte pas de sanctions particulières en soi, il est problématique lorsqu'il est mal utilisé. Dans une requête à table unique, cela fonctionne très bien. joignez maintenant cette table à une autre avec 20 colonnes, puis ajoutez des jointures à 5 autres tables avec plusieurs colonnes chacune. MAINTENANT, c'est un problème. Il en va de même pour les personnes qui enseignent un large pansement "ne faites jamais X" sans expliquer pourquoi.