¿Por qué SELECT * sería magnitudes más rápido que SELECT foo?

Considere una tabla de valores y hashes, así:

+------------+----------+------+-----+---------+----------------+
| 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 siguiente consulta finaliza en 0.00 segundos:

SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;

Sin embargo, esta consulta toma 3 min 17 segundos:

SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;

Veo que mientras se ejecuta la consulta, la lista de procesos la muestra como estado Sorting result. La situación es completamente reproducible. Tenga en cuenta que hay otro proceso que realiza INSERToperaciones en la tabla continuamente.

¿Por qué la consulta más específica tardaría más en ejecutarse que la *consulta? Siempre he creído que las *consultas deben evitarse específicamente por razones de rendimiento.

La frase se ORDER BY 1refiere a diferentes columnas; en el primero será id, en el segundo val. Como ides la clave, se indexará y order byserá una cantidad de trabajo trivial. Sin order by valembargo, para que el sistema tenga que recuperar cada fila, ordenar la tabla completa valy luego elegir solo una de esas filas.

Cambia ambas consultas order by idy creo que tus tiempos de ejecución serán casi idénticos.

MG explica bien la diferencia de rendimiento en su consulta. Voy a abordar esto:

Siempre he creído que las consultas * deben evitarse específicamente por razones de rendimiento.

select *no conlleva sanciones particulares por sí mismo, es problemático cuando se usa incorrectamente. En una consulta de una sola tabla, funciona bien. ahora une esa tabla a otra con 20 columnas, y luego agrega combinaciones a otras 5 tablas con muchas columnas cada una. AHORA es un problema. También lo son las personas que enseñan banda ancha, "nunca hacen X" sin explicar por qué.