mysql - funciones - grupo sql por versus distinto
funciones de agrupamiento en sql (5)
Ambos generarían el mismo plan de consulta en MS SQL Server ... Si tiene MS SQL Server, puede habilitar el plan de ejecución real para ver cuál es el mejor para sus necesidades ...
Por favor, eche un vistazo a esas publicaciones:
http://www.sqlmag.com/Article/ArticleID/24282/sql_server_24282.html
¿Por qué alguien usaría un grupo por frente a distinto cuando no hay agregaciones hechas 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 que pueden estar cerca de su equivalente allí, pero en MySQL, espero que una ventaja de rendimiento significativo sea distinta.
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
Si realmente está buscando valores distintos, los distintos hacen que el código fuente sea más legible (como si fuera parte de un procedimiento almacenado). Si estoy escribiendo consultas ad-hoc usualmente comenzaré con el grupo, incluso si tengo sin agregaciones porque a menudo termino poniéndomelas.
Un poco (MUY poco) datos empíricos de MS SQL Server, en un par de tablas aleatorias de nuestro DB.
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 generaron 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 hubo un índice de cobertura, ambos produjeron:
|--Stream Aggregate(GROUP BY:([table].[col1], [table].[col2]))
|--Index Scan(OBJECT:([db].[dbo].[table].[IX_some_index]), ORDERED FORWARD)
por lo tanto, a partir de esa muestra muy pequeña, SQL Server ciertamente trata a ambos de la misma manera.
GROUP BY asigna grupos de filas a una fila, por valor distinto en columnas específicas , que ni siquiera necesariamente tienen que estar 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 sabe lo que está haciendo, seleccionando b , c y d de una manera no ambigua porque son dependencias funcionales de a .
Sin embargo, Microsoft SQL Server y otras marcas no permiten esta consulta, ya que no puede determinar fácilmente las dependencias funcionales. editar: en cambio, el SQL estándar requiere que usted siga la Regla de valor único , es decir, cada columna en la lista de selección debe ser nombrada en la cláusula GROUP BY o 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 concepto erróneo común que DISTINCT permite especificar las columnas:
SELECT DISTINCT(a), b, c FROM table1;
A pesar de que los paréntesis 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 conducirá a una fila distinta en el resultado de la consulta. Una de las expresiones en esta lista de selección tiene paréntesis a su alrededor, pero esto no afectará el resultado.
En MySQL, he encontrado que usar un GROUP BY a menudo es mejor en rendimiento que DISTINCT.
Al hacer una "EXPLAIN SELECT DISTINCT" se muestra "Using where; Using temporary" MySQL creará una tabla temporal.
vs a "EXPLAIN SELECT a, b, c from T1, T2 where T2.A = T1.A GROUP BY a" just shows "Using where"