MIN / MAX vs ORDER BY y LIMIT

100

De las siguientes consultas, ¿qué método consideraría mejor? ¿Cuáles son sus razones (eficiencia del código, mejor capacidad de mantenimiento, menos WTFery) ...

SELECT MIN(`field`)
FROM `tbl`;

SELECT `field`
FROM `tbl`
ORDER BY `field`
LIMIT 1;

sql mysql

— nickf
fuente

126

En el peor de los casos, cuando está mirando un campo no indexado, el uso MIN()requiere una sola pasada completa de la tabla. El uso de SORTy LIMITrequiere un ordenamiento de archivos. Si se ejecuta contra una mesa grande, es probable que haya una diferencia significativa en el rendimiento percibido. Como un punto de datos sin sentido, MIN()tomé .36s mientras SORTy LIMITtomé .84s contra una tabla de 106,000 filas en mi servidor de desarrollo.

Sin embargo, si está mirando una columna indexada, la diferencia es más difícil de notar (el punto de datos sin sentido es 0.00 s en ambos casos). Sin embargo, al observar la salida de la explicación, parece que MIN()puede simplemente extraer el valor más pequeño del índice ('Seleccionar tablas optimizadas' y filas 'NULL') mientras que SORTy LIMITtodavía necesita hacer un recorrido ordenado del índice (106.000 filas). El impacto real en el rendimiento probablemente sea insignificante.

Parece que MIN()es el camino a seguir: es más rápido en el peor de los casos, indistinguible en el mejor de los casos, es SQL estándar y expresa con mayor claridad el valor que está tratando de obtener. El único caso en el que parece que usar SORTy LIMITsería deseable sería, como mencionó mson , donde está escribiendo una operación general que encuentra los valores N superiores o inferiores de columnas arbitrarias y no vale la pena escribir la operación de caso especial.

— Sean McSomething
fuente

7

o (n) para una sola pasada vs 0 (nlogn) para clasificación

— Abhishek Iyer

1

@AbhishekIyer tiene toda la razón, pero agregaría "en el peor de los casos para un campo no indexado".

— dmikam

Esa parte sobre el peor caso no indexado está mal. Siempre necesitas un escaneo completo, ¿de qué otra manera sabes que es un mínimo o un máximo? No es como si estuvieras escaneando y el valor grita: "¡Oye, finalmente me encontraste! ¡Soy Jack, el máximo!".

— Robo Robok

En una prueba con una tabla indexada con 470 millones de filas, ambas consultas toman 0.00 s. Sin embargo, si agregamos a las consultas un filtro "WHERE field2 = x", la consulta con LIMIT aún toma 0.00 sy la consulta con MIN toma 0.21 s.

— Antonio Cañas Vargas

12

SELECT MIN(`field`)
FROM `tbl`;

Simplemente porque es compatible con ANSI. El límite 1 es particular de MySql como TOP es de SQL Server.

— Otávio Décio
fuente

La mayoría de los DBMS tienen límite / compensación o equivalente, y se usa en la mayoría de las aplicaciones en las que he trabajado (no como una alternativa a MIN, sino para otros fines, como la paginación).

— finnw

@finnw: estoy de acuerdo, pero el ejemplo del interrogador fue comparar el límite con el mínimo explícitamente.

— Otávio Décio

9

Como han señalado mson y Sean McSomething , es preferible MIN.

Otra razón por la que ORDER BY + LIMIT es útil es si desea obtener el valor de una columna diferente a la columna MIN.

Ejemplo:

SELECT some_other_field, field
FROM tbl
ORDER BY field
LIMIT 1

— usuario650654
fuente

4

Creo que las respuestas dependen de lo que estés haciendo.

Si tiene una consulta de 1 off y la intención es tan simple como especificó, es preferible seleccionar min (campo).

Sin embargo, es común que estos tipos de requisitos se conviertan en: obtener los primeros n resultados, obtener los n-ésimos resultados, etc.

No creo que sea una idea demasiado terrible comprometerse con la base de datos elegida. Cambiar dbs no debe hacerse a la ligera y hay que revisar el precio que paga cuando hace este movimiento.

¿Por qué limitarse ahora, por el dolor que puede sentir o no más adelante?

Creo que es bueno seguir siendo ANSI tanto como sea posible, pero eso es solo una guía ...

— mson
fuente

3

Con un rendimiento aceptable, usaría el primero porque está semánticamente más cerca de la intención.
Si el rendimiento fuera un problema (la mayoría de los optimizadores modernos probablemente optimizarán ambos para el mismo plan de consulta, aunque debe probarlo para verificarlo) entonces, por supuesto, usaría el más rápido.

— Charles Bretana
fuente