¿Qué es más rápido, SELECT DISTINCT o GROUP BY en MySQL?

Si tengo una mesa

CREATE TABLE users (
  id int(10) unsigned NOT NULL auto_increment,
  name varchar(255) NOT NULL,
  profession varchar(255) NOT NULL,
  employer varchar(255) NOT NULL,
  PRIMARY KEY  (id)
)

y quiero obtener todos los valores únicos de professioncampo, lo que sería más rápido (o recomendado):

SELECT DISTINCT u.profession FROM users u

o

SELECT u.profession FROM users u GROUP BY u.profession

?

Son esencialmente equivalentes entre sí (de hecho, así es como algunas bases de datos se implementan DISTINCTbajo el capó).

Si uno de ellos es más rápido, lo será DISTINCT. Esto se debe a que, aunque los dos son iguales, un optimizador de consultas debería detectar el hecho de que GROUP BYno se está aprovechando de ningún miembro del grupo, solo de sus claves. DISTINCTlo hace explícito, para que pueda salirse con la suya con un optimizador ligeramente más tonto.

En caso de duda, prueba!

Si tiene un índice profession, estos dos son sinónimos.

Si no lo haces, entonces úsalo DISTINCT.

GROUP BYen MySQLespecie resultados. Incluso puedes hacer:

SELECT u.profession FROM users u GROUP BY u.profession DESC

y ordena tus profesiones en DESCorden.

DISTINCTcrea una tabla temporal y la usa para almacenar duplicados. GROUP BYhace lo mismo, pero sortes los resultados distintos después.

Entonces

SELECT DISTINCT u.profession FROM users u

es más rápido si no tiene un índice activado profession.

Todas las respuestas anteriores son correctas, para el caso de DISTINCT en una sola columna vs GROUP BY en una sola columna. Cada motor db tiene su propia implementación y optimizaciones, y si le importa la muy pequeña diferencia (en la mayoría de los casos), ¡entonces tiene que probar con un servidor específico Y una versión específica! Como las implementaciones pueden cambiar ...

PERO, si selecciona más de una columna en la consulta, ¡entonces DISTINCT es esencialmente diferente! Porque en este caso comparará TODAS las columnas de todas las filas, en lugar de solo una columna.

Entonces, si tienes algo como:

// This will NOT return unique by [id], but unique by (id,name)
SELECT DISTINCT id, name FROM some_query_with_joins

// This will select unique by [id].
SELECT id, name FROM some_query_with_joins GROUP BY id

Es un error común pensar que la palabra clave DISTINCT distingue filas por la primera columna que especificó, pero DISTINCT es una palabra clave general de esta manera.

Por lo tanto, debe tener cuidado de no tomar las respuestas anteriores como correctas para todos los casos ... ¡Podría confundirse y obtener los resultados incorrectos mientras que todo lo que quería era optimizar!

Elija lo más simple y lo más breve posible: DISTINCT parece ser más lo que está buscando solo porque le dará EXACTAMENTE la respuesta que necesita y ¡solo eso!

Agrupar por es costoso que Distinct ya que Agrupar por hace una clasificación del resultado mientras que distinto lo evita. Pero si desea hacer que group by produce el mismo resultado que distinto, ordene por nulo .

SELECT DISTINCT u.profession FROM users u

es igual a

SELECT u.profession FROM users u GROUP BY u.profession order by null

bien distinto puede ser más lento que el grupo en algunas ocasiones en postgres (no sé sobre otros dbs).

ejemplo probado:

postgres=# select count(*) from (select distinct i from g) a;

count 

10001
(1 row)

Time: 1563,109 ms

postgres=# select count(*) from (select i from g group by i) a;

count
10001
(1 row)

Time: 594,481 ms

http://www.pgsql.cz/index.php/PostgreSQL_SQL_Tricks_I

así que ten cuidado ... :)

Parece que las consultas no son exactamente las mismas. Al menos para MySQL.

Comparar:

1. describa el nombre del producto seleccionado de northwind.products
2. describa el nombre del producto seleccionado del grupo northwind.products por nombre del producto

La segunda consulta proporciona adicionalmente "Uso de ordenar archivos" en Extra.

En MySQL , " Group By" utiliza un paso adicional: filesort. Me doy cuenta de que DISTINCTes más rápido que GROUP BYeso, y eso fue una sorpresa.

Después de muchas pruebas, llegamos a la conclusión de que GROUP BY es más rápido

SELECCIONE sql_no_cache opnamegroep_intern DESDE telwerken DONDE opnemergroep(7,8,9,10,11,12,13) ​​grupo por opnamegroep_intern

635 total 0,0944 segundos Weergave van registra 0-29 (635 total, consulta duurde 0,0484 segundos)

SELECCIONE sql_no_cache distinct (opnamegroep_intern) DESDE telwerken DONDE opnemergroepEN (7,8,9,10,11,12,13)

635 total 0.2117 segundos (casi 100% más lento) Weergave van registra 0-29 (635 total, consulta duurde 0.3468 seg)

(más de una nota funcional)

Hay casos en los que tiene que usar GROUP BY, por ejemplo, si desea obtener el número de empleados por empleador:

SELECT u.employer, COUNT(u.id) AS "total employees" FROM users u GROUP BY u.employer

En tal escenario DISTINCT u.employerno funciona bien. Quizás haya un camino, pero simplemente no lo sé. (Si alguien sabe cómo hacer una consulta con DISTINCT, ¡agregue una nota!)

Aquí hay un enfoque simple que imprimirá los 2 tiempos transcurridos diferentes para cada consulta.

DECLARE @t1 DATETIME;
DECLARE @t2 DATETIME;

SET @t1 = GETDATE();
SELECT DISTINCT u.profession FROM users u; --Query with DISTINCT
SET @t2 = GETDATE();
PRINT 'Elapsed time (ms): ' + CAST(DATEDIFF(millisecond, @t1, @t2) AS varchar);

SET @t1 = GETDATE();
SELECT u.profession FROM users u GROUP BY u.profession; --Query with GROUP BY
SET @t2 = GETDATE();
PRINT 'Elapsed time (ms): ' + CAST(DATEDIFF(millisecond, @t1, @t2) AS varchar);

O pruebe SET STATISTICS TIME (Transact-SQL)

SET STATISTICS TIME ON;
SELECT DISTINCT u.profession FROM users u; --Query with DISTINCT
SELECT u.profession FROM users u GROUP BY u.profession; --Query with GROUP BY
SET STATISTICS TIME OFF;

Simplemente muestra el número de milisegundos necesarios para analizar, compilar y ejecutar cada instrucción de la siguiente manera:

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 2 ms.

Esto no es una regla

Para cada consulta ... intente por separado y luego agrupe por ... compare el tiempo para completar cada consulta y use el más rápido ...

En mi proyecto, a veces uso group by y otros distintos

Si no tiene que hacer ninguna función de grupo (suma, promedio, etc. en caso de que desee agregar datos numéricos a la tabla), use SELECT DISTINCT. Sospecho que es más rápido, pero no tengo nada que mostrar.

En cualquier caso, si le preocupa la velocidad, cree un índice en la columna.

SELECT DISTINCT siempre será el mismo, o más rápido, que GROUP BY. En algunos sistemas (es decir, Oracle), puede estar optimizado para ser el mismo que DISTINCT para la mayoría de las consultas. En otros (como SQL Server), puede ser considerablemente más rápido.

Si el problema lo permite, intente con EXISTS, ya que está optimizado para terminar tan pronto como se encuentre un resultado (y no almacene ninguna respuesta), por lo tanto, si solo está tratando de normalizar los datos para una cláusula WHERE como esta

SELECT FROM SOMETHING S WHERE S.ID IN ( SELECT DISTINCT DCR.SOMETHING_ID FROM DIFF_CARDINALITY_RELATIONSHIP DCR ) -- to keep same cardinality

Una respuesta más rápida sería:

SELECT FROM SOMETHING S WHERE EXISTS ( SELECT 1 FROM DIFF_CARDINALITY_RELATIONSHIP DCR WHERE DCR.SOMETHING_ID = S.ID )

Esto no siempre es posible, pero cuando esté disponible, verá una respuesta más rápida.