Pregunta

¿Por qué alguien usaría un grupo por versus distinto cuando no se realizan agregaciones en la consulta?

Además, ¿alguien conoce el grupo en comparación con las distintas consideraciones de rendimiento en MySQL y SQL Server. Supongo que SQL Server tiene un mejor optimizador y podrían ser casi equivalentes allí, pero en MySQL, espero una ventaja de rendimiento significativa para distinguir.

Estoy interesado en las respuestas de dba.

EDITAR:

La publicación de Bill es interesante, pero no aplicable. Déjame ser más específico ...

select a, b, c 
from table x
group by a, b,c

versus

select distinct a,b,c
from table x
¿Fue útil?

Solución

Un poco (MUY poco) de datos empíricos de MS SQL Server, en un par de tablas aleatorias de nuestra base de datos.

Para el patrón:

SELECT col1, col2 FROM table GROUP BY col1, col2

y

SELECT DISTINCT col1, col2 FROM table 

Cuando no hay un índice de cobertura para la consulta, ambas formas producen el siguiente plan de consulta:

|--Sort(DISTINCT ORDER BY:([table].[col1] ASC, [table].[col2] ASC))
   |--Clustered Index Scan(OBJECT:([db].[dbo].[table].[IX_some_index]))

y cuando había un índice de cobertura, ambos producían:

|--Stream Aggregate(GROUP BY:([table].[col1], [table].[col2]))
   |--Index Scan(OBJECT:([db].[dbo].[table].[IX_some_index]), ORDERED FORWARD)

así que de esa muestra muy pequeña, SQL Server ciertamente trata a los dos de la misma manera.

Otros consejos

GROUP BY asigna grupos de filas a una fila, por valor distinto en columnas específicas , que ni siquiera tienen que estar necesariamente en la lista de selección.

SELECT b, c, d FROM table1 GROUP BY a;

Esta consulta es SQL legal ( corrección: solo en MySQL; en realidad no es SQL estándar y no es compatible con otras marcas). MySQL lo acepta, y confía en que sabes lo que estás haciendo, seleccionando b , c y d de una manera inequívoca porque dependencias funcionales de a .

Sin embargo, Microsoft SQL Server y otras marcas no permiten esta consulta, ya que no puede determinar las dependencias funcionales fácilmente. editar: En cambio, el SQL estándar requiere que sigas la Regla de un solo valor , es decir, cada columna de la lista de selección debe nombrarse en el GROUP BY cláusula o bien ser un argumento para una función establecida.

Mientras que DISTINCT siempre mira todas las columnas en la lista de selección, y solo esas columnas. Es un error común pensar que DISTINCT le permite especificar las columnas:

SELECT DISTINCT(a), b, c FROM table1;

A pesar de los paréntesis que hacen que DISTINCT parezca una llamada a función, no lo es. Es una opción de consulta y un valor distinto en cualquiera de los tres campos de la lista de selección dará lugar a una fila distinta en el resultado de la consulta. Una de las expresiones en esta lista de selección tiene paréntesis, pero esto no afectará el resultado.

En MySQL he encontrado que usar GROUP BY a menudo es mejor en rendimiento que DISTINCT.

Hacer una " EXPLICAR SELECCIONAR DISTINCT " muestra " Usando dónde; Usando temporal " MySQL creará una tabla temporal.

vs a '' EXPLICAR SELECCIONAR a, b, c de T1, T2 donde T2.A = T1.A GRUPO POR a '' solo muestra " Usando donde "

Ambos generarían el mismo plan de consulta en MS SQL Server ... Si tiene MS SQL Server, podría habilitar el plan de ejecución real para ver cuál es mejor para sus necesidades ...

Por favor, eche un vistazo a esas publicaciones:

http://blog.sqlauthority.com/2007/03/29/sql-server-difference-between-distinct-and-group-by-distinct-vs-group-by/

http://www.sqlmag.com/Article/ArticleID/24282 /sql_server_24282.html

Si realmente está buscando valores distintos, el distintivo hace que el código fuente sea más legible (como si fuera parte de un procedimiento almacenado) Si estoy escribiendo consultas ad-hoc, generalmente comenzaré con el grupo, incluso si no tengo agregaciones porque a menudo terminaré poniéndolas.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top