Y a-t-il une différence entre GROUP BY et DISTINCT


310

J'ai appris quelque chose de simple sur SQL l'autre jour:

SELECT c FROM myTbl GROUP BY C

A le même résultat que:

SELECT DISTINCT C FROM myTbl

Ce que je suis curieux de savoir, y a-t-il quelque chose de différent dans la façon dont un moteur SQL traite la commande, ou est-ce vraiment la même chose?

Personnellement, je préfère la syntaxe distincte, mais je suis sûr que c'est plus par habitude qu'autre chose.

EDIT: Ce n'est pas une question sur les agrégats. L'utilisation de GROUP BYavec des fonctions d'agrégation est comprise.


11
Ce n'est pas une question sur les agrégats, c'est un GROUPE BY fonctionnant de la même manière qu'un distinct quand aucune fonction d'agrégat n'est présente
Brettski

2
Vous pouvez aussi faire SELECT c FROM myTbl UNION SELECT c FROM myTblet obtenir le même résultat ... Mais pourquoi compliquer les choses lorsque SELECT DISTINCT est si facile.
jarlh

L '«ordre logique d'exécution» de GROUP BYest bien plus ancien que «SELECT» et DISTINCTsuit select.
Used_By_Already

Une différence très mineure que je n'ai pas vue mentionnée est que cela DISTINCTaboutit à sélectionner réellement le champ - c'est-à-dire que la valeur apparaîtra dans le jeu de résultats. GROUP BYpeut supprimer efficacement les doublons sans sélectionner le champ. Ceci est quelque peu hors de propos dans la plupart des cas, mais pourrait être exactement ce que vous voulez dans d'autres. Si vous finissez par utiliser GROUP BYà la place de DISTINCT, un commentaire explicatif dans le code est probablement justifié.
rinogo

L'essentiel semble être que, comme la suppression des doublons se produit à différents points du plan d'exécution, l'une peut être plus efficace que l'autre car la suppression des doublons nécessite un tri ou peut-être une utilisation de cet index par rapport à cet index. Ainsi, il peut y avoir un avantage à retirer le dup tôt ou l'avantage peut provenir de l'utilisation précoce d'un index différent et de manger un tri plus tard quand il y a peu de rangées et que le tri est négligeable.
bielawski

Réponses:


246

La réponse de MusiGenesis est fonctionnellement la bonne en ce qui concerne votre question, comme indiqué; SQL Server est suffisamment intelligent pour se rendre compte que si vous utilisez "Grouper par" et que vous n'utilisez aucune fonction d'agrégation, ce que vous voulez dire par là est "Distinct" - et donc il génère un plan d'exécution comme si vous aviez simplement utilisé "Distinct" . "

Cependant, je pense qu'il est important de noter également la réponse de Hank - le traitement cavalier de "Group By" et "Distinct" pourrait conduire à des accrochages pernicieux si vous n'y faites pas attention. Il n'est pas tout à fait correct de dire qu'il ne s'agit "pas d'une question sur les agrégats", car vous posez des questions sur la différence fonctionnelle entre deux mots clés de requête SQL, dont l'un est destiné à être utilisé avec des agrégats et l'autre non.

Un marteau peut parfois fonctionner pour enfoncer une vis, mais si vous avez un tournevis à portée de main, pourquoi vous embêter?

(aux fins de cette analogie, Hammer : Screwdriver :: GroupBy : Distinctet screw => get list of unique values in a table column)


Je suis entièrement d'accord avec vous Skeolan. J'ai été assez surpris lorsque j'ai découvert cette fonctionnalité. Ce n'est pas quelque chose que je prévois d'utiliser, mais une façon dont les choses ont été faites dans ce nouvel endroit où je travaille.
Brettski

Au moins dans Oracle 12, il semble y avoir des cas où DISTINCT, l'obtention de valeurs distinctes par UNION et GROUP BY fonctionnent différemment. J'ai eu un cas plus tôt dans la journée où DISTINCT et distinct par UNION provoquent une erreur oracle, mais GROUP BY a fonctionné; Je sélectionnais seulement 1 colonne dans une vue et n'utilisais aucune agrégation; Je suis toujours perplexe quant à la raison pour laquelle cela était requis, mais cela confirme qu'il y a une différence dans l'exécution. Comme d'autres le soulignent, il vous permet également de regrouper les colonnes ne figurant pas dans la sélection, bien que cela devrait rarement être nécessaire sans agrégation.
ZeroK

1
En ce qui concerne SQL, vous disposez toujours d'un tournevis et d'un marteau. Pourquoi utiliser un marteau pour enfoncer une vis?
jarlh

Juste pour être clair en ce qui concerne votre analogie - votre marteau == GroupBy et votre tournevis == sont-ils distincts dans ce cas?
HopeKing

Wow, cette question de dix ans a encore des jambes! "Distinct" est le tournevis, si "list of unique values" est la vis. Je mettrai à jour la réponse pour rendre l'analogie plus claire.
Skeolan

136

GROUP BYvous permet d' utiliser des fonctions d' agrégation, comme AVG, MAX, MIN, SUMet COUNT. D'un autre côté, DISTINCTsupprime simplement les doublons.

Par exemple, si vous avez un tas d'enregistrements d'achat et que vous voulez savoir combien a été dépensé par chaque département, vous pouvez faire quelque chose comme:

SELECT department, SUM(amount) FROM purchases GROUP BY department

Cela vous donnera une ligne par département, contenant le nom du département et la somme de toutes les amountvaleurs de toutes les lignes pour ce département.


2
L'utilisation de GROUP BY Je comprends, la question est basée sur le fait qu'il renvoie un ensemble de données distinct lorsqu'aucune fonction d'agrégation n'est présente.
Brettski

2
Parce que GROUP BY fait implicitement un DISTINCT sur les valeurs de la colonne que vous regroupez (désolé pour la cacophonie).
Joe Pineda

N'est-il pas possible d'utiliser DISTINCT+ une fonction d'agrégation? comme ceci:select distinct department, SUM(amount) from ...
Shafizadeh

@Sajad, vous pouvez le faire oui, mais vous devez toujours avoir le GROUP BY, donc le DISTINCT ne fait rien pour vous.
ZeroK

44

Il n'y a aucune différence (dans SQL Server, au moins). Les deux requêtes utilisent le même plan d'exécution.

http://sqlmag.com/database-performance-tuning/distinct-vs-group

Peut - être est une différence, s'il y a des sous-requêtes impliquées:

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

Il n'y a pas de différence (style Oracle):

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:32961403234212


40

Quelle est la différence d'un simple point de vue de la fonctionnalité de suppression des doublons

Outre le fait que, contrairement à DISTINCT, GROUP BYpermet d'agréger des données par groupe (qui a été mentionné par de nombreuses autres réponses), la différence la plus importante à mon avis est le fait que les deux opérations "se produisent" à deux étapes très différentes dans l' ordre logique des opérations qui sont exécutées dans une SELECTinstruction .

Voici les opérations les plus importantes:

  • FROM(y compris JOIN, APPLY, etc.)
  • WHERE
  • GROUP BY (peut supprimer les doublons)
  • Agrégations
  • HAVING
  • Fonctions de fenêtre
  • SELECT
  • DISTINCT (peut supprimer les doublons)
  • UNION, INTERSECT, EXCEPT (Peut supprimer les doublons)
  • ORDER BY
  • OFFSET
  • LIMIT

Comme vous pouvez le voir, l'ordre logique de chaque opération influence ce qui peut être fait avec elle et comment elle influence les opérations suivantes. En particulier, le fait que l' GROUP BYopération "se passe avant" l' SELECTopération (la projection) signifie que:

  1. Cela ne dépend pas de la projection (ce qui peut être un avantage)
  2. Il ne peut utiliser aucune valeur de la projection (ce qui peut être un inconvénient)

1. Cela ne dépend pas de la projection

Un exemple où ne pas dépendre de la projection est utile est si vous voulez calculer des fonctions de fenêtre sur des valeurs distinctes:

SELECT rating, row_number() OVER (ORDER BY rating) AS rn
FROM film
GROUP BY rating

Lorsqu'il est exécuté sur la base de données Sakila , cela donne:

rating   rn
-----------
G        1
NC-17    2
PG       3
PG-13    4
R        5

La même chose ne pouvait pas être obtenue avec DISTINCTfacilement:

SELECT DISTINCT rating, row_number() OVER (ORDER BY rating) AS rn
FROM film

Cette requête est "fausse" et donne quelque chose comme:

rating   rn
------------
G        1
G        2
G        3
...
G        178
NC-17    179
NC-17    180
...

Ce n'est pas ce que nous voulions. L' DISTINCTopération "se produit après" la projection, nous ne pouvons donc plus supprimer les DISTINCTclassements car la fonction fenêtre a déjà été calculée et projetée. Pour l'utiliser DISTINCT, nous devons imbriquer cette partie de la requête:

SELECT rating, row_number() OVER (ORDER BY rating) AS rn
FROM (
  SELECT DISTINCT rating FROM film
) f

Note: Dans ce cas particulier, nous pourrions également utiliserDENSE_RANK()

SELECT DISTINCT rating, dense_rank() OVER (ORDER BY rating) AS rn
FROM film

2. Il ne peut utiliser aucune valeur de la projection

L'un des inconvénients de SQL est parfois sa verbosité. Pour la même raison que ce que nous avons vu auparavant (à savoir l'ordre logique des opérations), nous ne pouvons pas "facilement" grouper par quelque chose que nous projetons.

Il s'agit d'un SQL non valide:

SELECT first_name || ' ' || last_name AS name
FROM customer
GROUP BY name

Ceci est valide (en répétant l'expression)

SELECT first_name || ' ' || last_name AS name
FROM customer
GROUP BY first_name || ' ' || last_name

Ceci est également valable (imbriquer l'expression)

SELECT name
FROM (
  SELECT first_name || ' ' || last_name AS name
  FROM customer
) c
GROUP BY name

J'ai écrit sur ce sujet plus en profondeur dans un article de blog


Honnêtement, j'ai été surpris de voir que l'ordre d'exécution n'a pas été discuté immédiatement sur cette question. Merci, très bien expliqué aussi. Sur votre point 2. certains (un?) Db permettent l'utilisation d'alias sélectionnés tout au long de la requête (celui que je connais est Teradata, mais c'est une exception).
Used_By_Already

@Used_By_Already: Bien sûr, certaines bases de données le font. De nombreuses bases de données autorisent l'utilisation de ces alias uniquement dans certaines parties (par exemple, pas WHEREmais peut-être GROUP BY). En tout cas, je pense que c'est une mauvaise idée et je suggère de ne jamais utiliser cette fonctionnalité pour des raisons de portabilité et de maintenance. "Soudainement", cela ne fonctionnera plus, par exemple lors du crénelage d'une fonction d'agrégation ou d'une fonction de fenêtre.
Lukas Eder

never using that feature for portability and maintenance reasons!! d'accord à 100% ... et j'encourage maintenant votre blog aussi, excellent travail. À votre santé.
Used_By_Already

32

À utiliser DISTINCTsi vous souhaitez simplement supprimer les doublons. Utilisez GROUPY BYsi vous voulez appliquer les opérateurs globaux ( MAX, SUM, GROUP_CONCAT, ..., ou une HAVINGclause).


19

Je m'attends à ce qu'il y ait la possibilité de différences subtiles dans leur exécution. J'ai vérifié les plans d'exécution pour deux requêtes fonctionnellement équivalentes dans ce sens dans Oracle 10g:

core> select sta from zip group by sta;

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |    58 |   174 |    44  (19)| 00:00:01 |
|   1 |  HASH GROUP BY     |      |    58 |   174 |    44  (19)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| ZIP  | 42303 |   123K|    38   (6)| 00:00:01 |
---------------------------------------------------------------------------

core> select distinct sta from zip;

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |    58 |   174 |    44  (19)| 00:00:01 |
|   1 |  HASH UNIQUE       |      |    58 |   174 |    44  (19)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| ZIP  | 42303 |   123K|    38   (6)| 00:00:01 |
---------------------------------------------------------------------------

L'opération intermédiaire est légèrement différente: "HASH GROUP BY" contre "HASH UNIQUE", mais les coûts estimés, etc. sont identiques. Je les ai ensuite exécutés avec le suivi activé et le nombre d'opérations réel était le même pour les deux (sauf que le second n'avait pas à effectuer de lectures physiques en raison de la mise en cache).

Mais je pense que parce que les noms des opérations sont différents, l'exécution suivrait des chemins de code quelque peu différents et cela ouvre la possibilité de différences plus importantes.

Je pense que vous devriez préférer la syntaxe DISTINCT à cet effet. Ce n'est pas seulement une habitude, cela indique plus clairement le but de la requête.


14

Pour la requête que vous avez publiée, elles sont identiques. Mais pour d'autres requêtes qui peuvent ne pas être vraies.

Par exemple, ce n'est pas la même chose que:

SELECT C FROM myTbl GROUP BY C, D

14

J'ai lu tous les commentaires ci-dessus, mais je n'ai vu personne signaler la principale différence entre Group By et Distinct à part le bit d'agrégation.

Distinct renvoie toutes les lignes, puis les dédoublonne, tandis que Grouper par déduplique les lignes lorsqu'elles sont lues par l'algorithme une par une.

Cela signifie qu'ils peuvent produire des résultats différents!

Par exemple, les codes ci-dessous génèrent des résultats différents:

SELECT distinct ROW_NUMBER() OVER (ORDER BY Name), Name FROM NamesTable

 SELECT ROW_NUMBER() OVER (ORDER BY Name), Name FROM NamesTable
GROUP BY Name

S'il y a 10 noms dans le tableau où 1 est un doublon d'un autre, la première requête renvoie 10 lignes tandis que la deuxième requête renvoie 9 lignes.

La raison est ce que j'ai dit ci-dessus pour qu'ils puissent se comporter différemment!


11
En effet, alors que vous ne faites que le regroupement Namedans la deuxième requête, le distinctmot clé s'applique à la fois aux colonnes Nameet à votre ROW_NUMBER()colonne dans la selectclause de la première requête. Si vous aviez également regroupé par la première colonne dans la deuxième requête, les requêtes auraient renvoyé les mêmes résultats.

Ceci est un résultat de la order of executiondes clauses SQL qui est (au sens général) FROM and ON (joins), WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY, de LIMIT / OFFSET / TOPsorte que la seconde requête les noms sont réduits en nombre par groupe par et plus tard le row_number () est appliqué résultant en une rangée par nom unique. Dans la première requête, row_number () est appliqué avant que le distinct soit appliqué, et en raison de la nature de la fonction row_number (), chaque ligne obtient un entier unique, donc chaque ligne est renvoyée même s'il y a des valeurs de nom répétées.
Used_By_Already

12

Si vous utilisez DISTINCT avec plusieurs colonnes, le jeu de résultats ne sera pas groupé comme il le fera avec GROUP BY, et vous ne pouvez pas utiliser les fonctions d'agrégation avec DISTINCT.


11

Ils ont une sémantique différente, même s'ils ont des résultats équivalents sur vos données particulières.


6

GROUP BY a une signification très spécifique qui est distincte (heh) de la fonction DISTINCT.

GROUP BY entraîne le regroupement des résultats de la requête à l'aide de l'expression choisie, des fonctions d'agrégation peuvent ensuite être appliquées et celles-ci agissent sur chaque groupe, plutôt que sur l'ensemble des résultats.

Voici un exemple qui pourrait vous aider:

Étant donné une table qui ressemble à ceci:

name
------
barry
dave
bill
dave
dave
barry
john

Cette requête:

SELECT name, count(*) AS count FROM table GROUP BY name;

Produira une sortie comme celle-ci:

name    count
-------------
barry   2
dave    3
bill    1
john    1

Ce qui est évidemment très différent de l'utilisation de DISTINCT. Si vous voulez grouper vos résultats, utilisez GROUP BY, si vous voulez juste une liste unique d'une colonne spécifique, utilisez DISTINCT. Cela donnera à votre base de données une chance d'optimiser la requête selon vos besoins.


6

Veuillez ne pas utiliser GROUP BY lorsque vous voulez dire DISTINCT, même s'ils fonctionnent de la même manière. Je suppose que vous essayez de réduire les millisecondes des requêtes, et je dois souligner que le temps du développeur est beaucoup plus cher que le temps de l'ordinateur.


5

Si vous utilisez un GROUP BY sans fonction d'agrégation, il sera traité en interne comme DISTINCT, donc dans ce cas il n'y a pas de différence entre GROUP BY et DISTINCT.

Mais lorsque la clause DISTINCT vous est fournie, il vaut mieux l'utiliser pour rechercher vos enregistrements uniques, car l'objectif de GROUP BY est de réaliser l'agrégation.


4

group by est utilisé dans les opérations d'agrégation - comme lorsque vous voulez obtenir un nombre de Bs décomposé par la colonne C

select C, count(B) from myTbl group by C

distinct est ce que cela ressemble - vous obtenez des lignes uniques.

Dans SQL Server 2005, il semble que l'optimiseur de requêtes soit en mesure d'optimiser la différence dans les exemples simplistes que j'ai exécutés. Je ne sais pas si vous pouvez compter sur cela dans toutes les situations.


3

Dans cette requête particulière, il n'y a aucune différence. Mais, bien sûr, si vous ajoutez des colonnes agrégées, vous devrez utiliser le regroupement par.


3

Dans la perspective Teradata :

D'un point de vue d'ensemble de résultats, peu importe si vous utilisez DISTINCT ou GROUP BY dans Teradata. L'ensemble de réponses sera le même.

Du point de vue des performances, ce n'est pas pareil.

Pour comprendre ce qui affecte les performances, vous devez savoir ce qui se passe sur Teradata lors de l'exécution d'une instruction avec DISTINCT ou GROUP BY.

Dans le cas de DISTINCT, les lignes sont redistribuées immédiatement sans aucune pré-agrégation, tandis que dans le cas de GROUP BY, dans une première étape, une pré-agrégation est effectuée et ce n'est qu'alors que les valeurs uniques sont redistribuées entre les AMP.

Ne pensez pas maintenant que GROUP BY est toujours meilleur du point de vue des performances. Lorsque vous avez plusieurs valeurs différentes, l'étape de pré-agrégation de GROUP BY n'est pas très efficace. Teradata doit trier les données pour supprimer les doublons. Dans ce cas, il peut être préférable de procéder à la redistribution en premier, c'est-à-dire d'utiliser l'instruction DISTINCT. Ce n'est que s'il existe de nombreuses valeurs en double que l'instruction GROUP BY est probablement le meilleur choix, car seulement une fois l'étape de déduplication effectuée, après redistribution.

En bref, DISTINCT vs GROUP BY dans Teradata signifie:

GROUP BY -> pour de nombreux doublons DISTINCT -> pas ou quelques doublons seulement. Parfois, lorsque vous utilisez DISTINCT, vous manquez d'espace de spoule sur un AMP. La raison en est que la redistribution a lieu immédiatement, et une asymétrie pourrait entraîner un manque d'espace pour les AMP.

Si cela se produit, vous avez probablement plus de chances avec GROUP BY, car les doublons sont déjà supprimés dans une première étape et moins de données sont déplacées entre les AMP.


Qu'est-ce que c'est Teradata?
Brettski

Teradata est un système de gestion de base de données relationnelle (SGBDR), capable de prendre en charge de nombreux utilisateurs simultanés à partir de diverses plates-formes clientes. Teradata est compatible avec la norme ANSI et repose entièrement sur une architecture parallèle.
Ram Ghadiyaram

2

Du point de vue «SQL le langage», les deux constructions sont équivalentes et celle que vous choisissez est l'un de ces choix de «style de vie» que nous devons tous faire. Je pense qu'il y a de bonnes raisons pour que DISTINCT soit plus explicite (et donc plus prévenant pour la personne qui héritera de votre code, etc.), mais cela ne signifie pas que la construction GROUP BY est un choix invalide.

Je pense que ce «GROUPE PAR est pour les agrégats» n'est pas le bon accent. Les gens doivent savoir que la fonction définie (MAX, MIN, COUNT, etc.) peut être omise afin qu'ils puissent comprendre l'intention du codeur lorsqu'elle l'est.

L'optimiseur idéal reconnaîtra les constructions SQL équivalentes et choisira toujours le plan idéal en conséquence. Pour votre moteur SQL réel de choix, vous devez tester :)

PS note que la position du mot-clé DISTINCT dans la clause select peut produire des résultats différents, par exemple le contraste:

SELECT COUNT(DISTINCT C) FROM myTbl;

SELECT DISTINCT COUNT(C) FROM myTbl;

1

Vous ne le remarquez que parce que vous sélectionnez une seule colonne.

Essayez de sélectionner deux champs et voyez ce qui se passe.

Group By est destiné à être utilisé comme ceci:

SELECT name, SUM(transaction) FROM myTbl GROUP BY name

Ce qui montrerait la somme de toutes les transactions pour chaque personne.


Il ne s'agit pas d'agrégats. Dans votre exemple, SELECT c, d FROM mytbl GROUP BY C, D; retournera en fait le même ensemble de données que SELECT DISTINCT C, D FROM mytbl; Ce sont les principes fondamentaux de la question
Brettski

1

Je sais que c'est un vieux poste. Mais il arrive que j'avais une requête qui utilisait le groupe juste pour renvoyer des valeurs distinctes lors de l'utilisation de cette requête dans les rapports toad et oracle, tout fonctionnait bien, je veux dire un bon temps de réponse. Lorsque nous avons migré d'Oracle 9i vers 11g, le temps de réponse dans Toad était excellent, mais dans le rapport, il a fallu environ 35 minutes pour terminer le rapport lors de l'utilisation de la version précédente, cela a pris environ 5 minutes.

La solution était de changer le groupe et d'utiliser DISTINCT et maintenant le rapport s'exécute en 30 secondes environ.

J'espère que cela est utile pour quelqu'un avec la même situation.


1

En termes d'utilisation, GROUP BY est utilisé pour regrouper les lignes que vous souhaitez calculer. DISTINCT ne fera aucun calcul. Il n'affichera aucune ligne en double.

J'ai toujours utilisé DISTINCT si je veux présenter des données sans doublons.

Si je veux faire des calculs comme résumer la quantité totale de mangues, j'utiliserai GROUP BY


0

La façon dont j'ai toujours compris, c'est que l'utilisation de distinct est identique au regroupement par chaque champ que vous avez sélectionné dans l'ordre dans lequel vous les avez sélectionnés.

c'est à dire:

select distinct a, b, c from table;

est le même que:

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

D'accord, mais serait-ce la même chose que sélectionner c, b, a dans le groupe de tables par a, b, c
Dheer

Oui, ce serait la même chose
Caius Jard

0

L'efficacité fonctionnelle est totalement différente. Si vous ne souhaitez sélectionner que la "valeur de retour", sauf celle en double, il est préférable d'utiliser distinct plutôt que de grouper par. Parce que "regrouper par" inclut (tri + suppression), "distinct" inclut (suppression)



0

Parfois, ils peuvent vous donner les mêmes résultats, mais ils sont destinés à être utilisés dans un sens / cas différent. La principale différence réside dans la syntaxe.

Notez attentivement l'exemple ci-dessous. DISTINCTest utilisé pour filtrer l'ensemble de valeurs en double. (6, cs, 9.1) et (1, cs, 5.5) sont deux ensembles différents. Donc, DISTINCTva afficher les deux lignes tandis que GROUP BY Branchva afficher un seul ensemble.

 SELECT * FROM student; 
+------+--------+------+
| Id   | Branch | CGPA |
+------+--------+------+
|    3 | civil  |  7.2 |
|    2 | mech   |  6.3 |
|    6 | cs     |  9.1 |
|    4 | eee    |  8.2 |
|    1 | cs     |  5.5 |
+------+--------+------+
5 rows in set (0.001 sec)

SELECT DISTINCT * FROM student; 
+------+--------+------+
| Id   | Branch | CGPA |
+------+--------+------+
|    3 | civil  |  7.2 |
|    2 | mech   |  6.3 |
|    6 | cs     |  9.1 |
|    4 | eee    |  8.2 |
|    1 | cs     |  5.5 |
+------+--------+------+
5 rows in set (0.001 sec)

SELECT * FROM student GROUP BY Branch;
+------+--------+------+
| Id   | Branch | CGPA |
+------+--------+------+
|    3 | civil  |  7.2 |
|    6 | cs     |  9.1 |
|    4 | eee    |  8.2 |
|    2 | mech   |  6.3 |
+------+--------+------+
4 rows in set (0.001 sec)

Parfois, les résultats qui peuvent être obtenus par GROUP BYclause ne peuvent pas être obtenus DISTINCTsans utiliser une clause ou des conditions supplémentaires. Par exemple, dans le cas ci-dessus.

Pour obtenir le même résultat que DISTINCTvous devez passer tous les noms de colonne dans la GROUP BYclause comme ci-dessous. Alors voyez la différence syntaxique. Vous devez avoir des connaissances sur tous les noms de colonne pour utiliser la GROUP BYclause dans ce cas.

SELECT * FROM student GROUP BY Id, Branch, CGPA;
+------+--------+------+
| Id   | Branch | CGPA |
+------+--------+------+
|    1 | cs     |  5.5 |
|    2 | mech   |  6.3 |
|    3 | civil  |  7.2 |
|    4 | eee    |  8.2 |
|    6 | cs     |  9.1 |
+------+--------+------+

J'ai également remarqué que GROUP BYles résultats sont affichés par ordre croissant par défaut, ce qui DISTINCTn'est pas le cas. Mais je n'en suis pas sûr. Il peut être différent selon le fournisseur.

Source: https://dbjpanda.me/dbms/languages/sql/sql-syntax-with-examples#group-by


0

Généralement, nous pouvons utiliser DISTINCTpour éliminer les doublons sur une colonne spécifique dans le tableau.

En cas de 'GROUP BY nous pouvons appliquer les fonctions d' agrégation comme AVG, MAX, MIN, SUMet COUNTsur la colonne spécifique et chercher le nom de la colonne et l' agrégation résultat de la fonction sur la même colonne.

Exemple :

select  specialColumn,sum(specialColumn) from yourTableName group by specialColumn;

-1

Il n'y a pas de différence significative entre group by et clause distincte à l'exception de l'utilisation de fonctions d'agrégation. Les deux peuvent être utilisés pour distinguer les valeurs, mais si en termes de performances, le groupe est meilleur. Lorsqu'un mot clé distinct est utilisé, il utilise en interne une opération de tri qui peut être affichée dans le plan d'exécution.

Essayez un exemple simple

Déclarez la table @tmpresult (Id tinyint)

Insérer dans @tmpresult Sélectionner 5 Union tout Sélectionner 2 Union tout Sélectionner 3 Union tout Sélectionner 4

Sélectionner un identifiant distinct dans @tmpresult


distincts et
groupés
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.