groupe sql par opposition à distinct

Question

Pourquoi quelqu'un utiliserait-il un groupe par opposition à distinct lorsqu'il n'y a pas d'agrégation dans la requête?

De même, quelqu'un connaît-il le groupe par considérations de performances distinctes dans MySQL et SQL Server? J'imagine que SQL Server possède un meilleur optimiseur et qu'ils sont peut-être presque équivalents, mais en MySQL, je m'attends à un avantage significatif en termes de performances.

Les réponses de DBA m'intéressent.

EDIT:

Le post de Bill est intéressant, mais non applicable. Permettez-moi d'être plus précis ...

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

versus

select distinct a,b,c
from table x

Answer 1

Quelques données (TRES peu) empiriques de MS SQL Server sur quelques tables aléatoires de notre base de données.

Pour le motif:

SELECT col1, col2 FROM table GROUP BY col1, col2

et

SELECT DISTINCT col1, col2 FROM table 

Lorsqu'il n'y a pas d'index de couverture pour la requête, le plan de requête suivant a été généré dans les deux sens:

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

et quand il y avait un indice de couverture, les deux produits:

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

donc, à partir de ce très petit exemple, SQL Server traite les deux à la fois.

Answer 2

GROUP BY mappe des groupes de lignes sur une ligne, par valeur distincte dans des colonnes spécifiques , qui ne doivent même pas nécessairement figurer dans la liste de sélection.

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

Cette requête est un SQL légal ( correction: uniquement dans MySQL; en réalité, ce n'est pas du SQL standard et n'est pas pris en charge par d'autres marques). MySQL l'accepte et il espère que vous saurez ce que vous faites en sélectionnant b , c et d de manière non ambiguë, car êtes dépendances fonctionnelles de a .

Cependant, Microsoft SQL Server et les autres marques n'autorisent pas cette requête car elle ne permet pas de déterminer facilement les dépendances fonctionnelles. modifier : à la place, le SQL standard exige que vous suiviez la règle à valeur unique , c'est-à-dire que chaque colonne de la liste de sélection doit être nommée dans le GROUP BY ou bien être un argument pour une fonction set.

Attendu que DISTINCT examine toujours toutes les colonnes de la liste de sélection, et uniquement ces colonnes. On croit souvent que DISTINCT vous permet de spécifier les colonnes:

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

Malgré les parenthèses qui font que DISTINCT ressemble à un appel de fonction, ce n'est pas le cas. C'est une option de requête et une valeur distincte dans l'un des trois champs de la liste de sélection mènera à une ligne distincte dans le résultat de la requête. Une des expressions de cette liste de sélection est entourée de parenthèses, mais cela n’affectera pas le résultat.

Answer 3

Sous MySQL, l'utilisation de GROUP BY est souvent plus performante que DISTINCT.

Réaliser un " EXPLAIN SELECT DISTINCT " montre "Utiliser où; Utilisation temporaire " MySQL créera une table temporaire.

vs a "EXPLAIN SELECT a, b, c de T1, T2 où T2.A = T1.A GROUP BY a" montre seulement "Utiliser où"

Answer 4

Les deux généreraient le même plan de requête dans MS SQL Server .... Si vous avez MS SQL Server, vous pouvez simplement activer le plan d'exécution réel pour déterminer celui qui convient le mieux à vos besoins ...

Veuillez regarder ces messages:

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

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

Answer 5

Si vous recherchez réellement des valeurs distinctes, distinct rend le code source plus lisible (comme s'il faisait partie d'une procédure stockée). Si j'écris des requêtes ad hoc, je commence généralement par le groupe, même si je n'ai pas d'agrégation parce que je vais souvent finir par les mettre.