Czy istnieje jakakolwiek różnica między GROUP BY a DISTINCT

Nauczyłem się czegoś prostego o SQL:

SELECT c FROM myTbl GROUP BY C

Ma taki sam wynik jak:

SELECT DISTINCT C FROM myTbl

Zastanawiam się, czy jest coś innego w sposobie przetwarzania polecenia przez silnik SQL, czy naprawdę są tym samym?

Ja osobiście wolę wyraźną składnię, ale jestem pewien, że jest to bardziej nawyk niż cokolwiek innego.

EDYCJA: To nie jest pytanie o agregaty. Zastosowanie GROUP BYfunkcji agregujących jest zrozumiałe.

Jak podano , odpowiedź MusiGenesis jest funkcjonalnie poprawna w odniesieniu do twojego pytania; SQL Server jest wystarczająco inteligentny, aby zdać sobie sprawę, że jeśli używasz „Grupuj według” i nie używasz żadnych funkcji agregujących, to tak naprawdę masz na myśli „Wyraźny” - i dlatego generuje plan wykonania, jakbyś po prostu użył „Wyróżniającego” . ”

Myślę jednak, że ważne jest, aby zauważyć również odpowiedź Hanka - kawalerskie traktowanie „Group By” i „Distinct” może prowadzić do pewnych zgubnych problemów, jeśli nie będziesz ostrożny. Nie jest całkowicie poprawne stwierdzenie, że nie jest to „pytanie o agregaty”, ponieważ pytasz o różnicę funkcjonalną między dwoma słowami kluczowymi zapytania SQL, z których jedno ma być używane z agregacjami, a jedno nie.

Czasami młotek może wbić śrubę, ale jeśli masz pod ręką śrubokręt, po co zawracać sobie głowę?

(dla celów tej analogii Hammer : Screwdriver :: GroupBy : Distincti screw => get list of unique values in a table column)

GROUP BYpozwala na korzystanie z funkcji agregujących, takich jak AVG, MAX, MIN, SUM, i COUNT. Z drugiej strony DISTINCTpo prostu usuwa duplikaty.

Na przykład, jeśli masz wiele rekordów zakupów i chcesz wiedzieć, ile wydał każdy dział, możesz zrobić coś takiego:

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

Otrzymasz jeden wiersz na dział zawierający nazwę działu i sumę wszystkich amountwartości we wszystkich wierszach dla tego działu.

Nie ma różnicy (przynajmniej w SQL Server). Oba zapytania wykorzystują ten sam plan wykonania.

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

Może nie ma różnicy, czy są sub-zapytań zaangażować:

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

Nie ma różnicy (w stylu Oracle):

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

Jaka jest różnica z punktu widzenia zwykłej funkcjonalności usuwania duplikatów

Oprócz tego, że w przeciwieństwie do DISTINCT, GROUP BYpozwala na agregowanie danych na grupę (o czym wspomniało wiele innych odpowiedzi), najważniejszą różnicą moim zdaniem jest fakt, że dwie operacje „zdarzają się” na dwóch bardzo różnych etapach w kolejności logicznej operacji wykonywanych w SELECTinstrukcji .

Oto najważniejsze operacje:

• FROM(w tym JOIN, APPLYetc.)
• WHERE
• GROUP BY (może usunąć duplikaty)
• Agregacje
• HAVING
• Funkcje okna
• SELECT
• DISTINCT (może usunąć duplikaty)
• UNION, INTERSECT, EXCEPT (Można usunąć duplikaty)
• ORDER BY
• OFFSET
• LIMIT

Jak widać, logiczna kolejność każdej operacji wpływa na to, co można z nią zrobić i jak wpływa na kolejne operacje. W szczególności, fakt, że GROUP BYdziałanie zachodzi „przed”, w SELECTpracy (projekcja) oznacza, że:

1. To nie zależy od projekcji (co może być zaletą)
2. Nie może używać żadnych wartości z rzutu (co może być wadą)

1. To nie zależy od projekcji

Przykładem, w którym nie jest zależne od rzutowania, jest użyteczny, jeśli chcesz obliczyć funkcje okna dla różnych wartości:

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

Po uruchomieniu z bazą danych Sakila daje to:

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

Tego samego nie da się DISTINCTłatwo osiągnąć :

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

To zapytanie jest „nieprawidłowe” i daje coś takiego:

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

Nie tego chcieliśmy. DISTINCTOperacja „dzieje się po” projekcji, więc nie możemy już usunąć DISTINCTocen, ponieważ funkcja okno zostało już obliczone i prognozowanych. Aby użyć DISTINCT, musielibyśmy zagnieździć tę część zapytania:

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

Uwaga dodatkowa: W tym konkretnym przypadku moglibyśmy również użyćDENSE_RANK()

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

2. Nie można użyć żadnych wartości z rzutu

Jedną z wad SQL jest czasami jego gadatliwość. Z tego samego powodu, co widzieliśmy wcześniej (mianowicie logicznej kolejności operacji), nie możemy „łatwo” pogrupować według czegoś, co projektujemy.

To jest nieprawidłowy SQL:

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

Jest to poprawne (powtarzanie wyrażenia)

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

Jest to również poprawne (zagnieżdżanie wyrażenia)

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

Bardziej szczegółowo napisałem na ten temat w poście na blogu

Użyj, DISTINCTjeśli chcesz usunąć duplikaty. Użyj GROUPY BY, jeśli chcesz zastosować operatory kruszywa ( MAX, SUM, GROUP_CONCAT, ..., czy HAVINGklauzula).

Oczekuję, że istnieje możliwość subtelnych różnic w ich wykonaniu. Sprawdziłem plany wykonania dla dwóch funkcjonalnie równoważnych zapytań wzdłuż tych linii w 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 |
---------------------------------------------------------------------------

Środkowa operacja jest nieco inna: „HASH GROUP BY” vs. „HASH UNIQUE”, ale szacowane koszty itp. Są identyczne. Następnie wykonałem je z włączonym śledzeniem, a faktyczne liczby operacji były takie same dla obu (z wyjątkiem tego, że drugi nie musiał wykonywać żadnych fizycznych odczytów z powodu buforowania).

Sądzę jednak, że ponieważ nazwy operacji są różne, wykonanie podążyłoby nieco innymi ścieżkami kodu, co otwiera możliwość poważniejszych różnic.

Myślę, że powinieneś w tym celu preferować składnię DISTINCT. To nie tylko nawyk, ale wyraźniej wskazuje cel zapytania.

W przypadku wysłanego zapytania są one identyczne. Ale w przypadku innych zapytań może to nie być prawda.

Na przykład to nie to samo, co:

SELECT C FROM myTbl GROUP BY C, D

Przeczytałem wszystkie powyższe komentarze, ale nie widziałem, aby ktokolwiek wskazywał na główną różnicę między Group By a Distinct oprócz bitu agregacji.

Distinct zwraca wszystkie wiersze, a następnie usuwa duplikaty, podczas gdy Group By usuwa deduplikację wierszy, gdy są one odczytywane przez algorytm jeden po drugim.

Oznacza to, że mogą wytwarzać różne wyniki!

Na przykład poniższe kody generują różne wyniki:

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

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

Jeśli w tabeli znajduje się 10 nazw, z których 1 jest duplikatem innej, pierwsze zapytanie zwraca 10 wierszy, a drugie zapytanie zwraca 9 wierszy.

Powodem jest to, co powiedziałem powyżej, aby mogli zachowywać się inaczej!

Jeśli użyjesz DISTINCT z wieloma kolumnami, zestaw wyników nie zostanie pogrupowany tak, jak w przypadku GROUP BY i nie możesz używać funkcji agregujących z DISTINCT.

Mają różną semantykę, nawet jeśli zdarzają się, że mają równoważne wyniki w twoich danych.

GROUP BY ma bardzo specyficzne znaczenie, które różni się (heh) od funkcji DISTINCT.

GROUP BY powoduje grupowanie wyników zapytania przy użyciu wybranego wyrażenia, wówczas można zastosować funkcje agregujące, które będą działać na każdej grupie, a nie na całym zestawie wyników.

Oto przykład, który może pomóc:

Biorąc pod uwagę tabelę, która wygląda następująco:

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

To zapytanie:

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

Wyprodukuje takie wyniki:

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

Co oczywiście różni się bardzo od używania DISTINCT. Jeśli chcesz pogrupować wyniki, użyj GROUP BY, jeśli chcesz tylko unikalną listę określonej kolumny, użyj DISTINCT. Dzięki temu Twoja baza danych będzie mogła zoptymalizować zapytanie pod kątem Twoich potrzeb.

Nie używaj GROUP BY, jeśli masz na myśli DISTINCT, nawet jeśli działają tak samo. Zakładam, że próbujesz zaoszczędzić milisekundy na zapytaniach i muszę zauważyć, że czas programisty jest o rząd wielkości większy niż czas komputerowy.

Jeśli używasz GROUP BY bez żadnej funkcji agregującej, to wewnętrznie będzie traktowane jako DISTINCT, więc w tym przypadku nie ma różnicy między GROUP BY i DISTINCT.

Ale kiedy otrzymasz klauzulę DISTINCT, lepiej użyj jej do znalezienia unikalnych rekordów, ponieważ celem GROUP BY jest osiągnięcie agregacji.

Grupowanie według jest używane w operacjach agregujących - na przykład gdy chcesz uzyskać liczbę Bs w podziale według kolumny C.

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

Wyraźnie to brzmi - otrzymujesz unikalne wiersze.

W SQL Server 2005 wygląda na to, że optymalizator zapytań jest w stanie zoptymalizować różnicę w uproszczonych przykładach, które uruchomiłem. Nie wiem, czy możesz na to liczyć we wszystkich sytuacjach.

W tym konkretnym zapytaniu nie ma różnicy. Ale oczywiście, jeśli dodasz jakieś kolumny agregujące, będziesz musiał użyć grupowania według.

W perspektywie Teradata :

Z punktu widzenia zestawu wyników nie ma znaczenia, czy użyjesz DISTINCT lub GROUP BY w Teradata. Zestaw odpowiedzi będzie taki sam.

Z punktu widzenia wydajności to nie to samo.

Aby zrozumieć, co wpływa na wydajność, musisz wiedzieć, co dzieje się na Teradata podczas wykonywania instrukcji za pomocą DISTINCT lub GROUP BY.

W przypadku DISTINCT wiersze są redystrybuowane natychmiast, bez konieczności przeprowadzania wstępnej agregacji, podczas gdy w przypadku GROUP BY, w pierwszym etapie przeprowadzana jest wstępna agregacja, a dopiero potem unikalne wartości są redystrybuowane między AMP.

Nie myśl teraz, że GROUP BY jest zawsze lepszy z punktu widzenia wydajności. Jeśli masz wiele różnych wartości, krok wstępnej agregacji GROUP BY nie jest zbyt wydajny. Teradata musi sortować dane, aby usunąć duplikaty. W takim przypadku lepiej może być najpierw redystrybucja, tzn. Użyj instrukcji DISTINCT. Tylko jeśli istnieje wiele zduplikowanych wartości, instrukcja GROUP BY jest prawdopodobnie lepszym wyborem, ponieważ tylko wtedy, gdy ma miejsce krok deduplikacji, po redystrybucji.

W skrócie, DISTINCT vs. GROUP BY w Teradata oznacza:

GRUPUJ WEDŁUG -> dla wielu duplikatów ODRÓŻNIJ -> brak lub tylko kilka duplikatów. Czasami, gdy używasz DISTINCT, zabrakło miejsca na buforze w AMP. Powodem jest to, że redystrybucja odbywa się natychmiast, a przekrzywienie może spowodować brak miejsca w AMP.

Jeśli tak się stanie, prawdopodobnie masz większą szansę na GROUP BY, ponieważ duplikaty są już usuwane w pierwszym kroku, a mniej danych jest przenoszonych między AMP.

Z punktu widzenia „języka SQL” obie konstrukcje są równoważne i który wybierzesz, jest jednym z wyborów „stylu życia”, które wszyscy musimy podjąć. Myślę, że jest dobry argument, aby DISTINCT był bardziej wyraźny (i dlatego jest bardziej rozważny dla osoby, która odziedziczy twój kod itp.), Ale to nie znaczy, że konstrukcja GROUP BY jest nieprawidłowym wyborem.

Myślę, że to „GROUP BY jest dla agregatów” jest niewłaściwe. Folk powinien być świadomy, że ustawioną funkcję (MAKS, MIN, LICZBA, itp.) Można pominąć, aby mogli zrozumieć zamiary kodera, gdy jest.

Idealny optymalizator rozpozna równoważne konstrukcje SQL i zawsze odpowiednio wybierze idealny plan. Aby wybrać rzeczywisty silnik SQL, musisz przetestować :)

PS zauważ, że pozycja słowa kluczowego DISTINCT w klauzuli select może dawać różne wyniki, np. Kontrast:

SELECT COUNT(DISTINCT C) FROM myTbl;

SELECT DISTINCT COUNT(C) FROM myTbl;

Zauważasz to tylko dlatego, że wybierasz jedną kolumnę.

Spróbuj wybrać dwa pola i zobacz, co się stanie.

Group By jest przeznaczony do użycia w następujący sposób:

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

Który pokazywałby sumę wszystkich transakcji dla każdej osoby.

Wiem, że to stary post. Ale zdarza się, że miałem zapytanie, które wykorzystywało grupę tylko po to, aby zwrócić różne wartości podczas używania tego zapytania w raportach ropuchy i wyroczni wszystko działało dobrze, mam na myśli dobry czas odpowiedzi. Kiedy przeprowadziliśmy migrację z Oracle 9i do 11g, czas reakcji w Toad był doskonały, ale w raporcie ukończenie raportu zajęło około 35 minut przy użyciu poprzedniej wersji około 5 minut.

Rozwiązaniem było zmienić grupę i użyć DISTINCT, a teraz raport jest uruchamiany za około 30 sekund.

Mam nadzieję, że jest to przydatne dla kogoś w tej samej sytuacji.

Jeśli chodzi o użycie, GROUP BY służy do grupowania wierszy, które chcesz obliczyć. DISTINCT nie wykona żadnych obliczeń. Nie będzie pokazywał duplikatów wierszy.

Zawsze użyłem DISTINCT, jeśli chcę prezentować dane bez duplikatów.

Jeśli chcę wykonać obliczenia, takie jak sumowanie całkowitej ilości mango, skorzystam z GROUP BY

Zawsze rozumiałem, że użycie odróżnienia jest takie samo jak grupowanie według każdego pola, które wybrałeś w kolejności, w jakiej je wybrałeś.

to znaczy:

select distinct a, b, c from table;

jest taki sam jak:

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

Wydajność funkcjonalna jest zupełnie inna. Jeśli chcesz wybrać tylko „wartość zwracaną” oprócz zduplikowanej, użyj odrębnego jest lepsze niż grupowanie według. Ponieważ „grupuj według” obejmuje (sortowanie + usuwanie), „odrębne” obejmuje (usuwanie)

W gałęzi (HQL) grupowanie według może być znacznie szybsze niż rozróżnianie, ponieważ ten pierwszy nie wymaga porównywania wszystkich pól w tabeli. Zobacz https://sqlperformance.com/2017/01/t-sql-queries/surprises-assumptions-group-by-distinct .

Czasami mogą dać te same wyniki, ale mają być stosowane w innym znaczeniu / przypadku. Główną różnicą jest składnia.

Zwróć uwagę na poniższy przykład. DISTINCTsłuży do odfiltrowania zduplikowanego zestawu wartości. (6, cs, 9.1) i (1, cs, 5.5) to dwa różne zestawy. Tak DISTINCTsię dzieje, aby wyświetlić oba wiersze natomiast GROUP BY Branchbędzie wyświetlać tylko jeden zestaw.

 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)

Czasami wyniki, które można osiągnąć za pomocą GROUP BYklauzuli, nie są możliwe do osiągnięciaDISTINCT bez zastosowania dodatkowej klauzuli lub warunków. Np. W powyższym przypadku.

Aby uzyskać taki sam wynik, jak DISTINCTtrzeba przekazać wszystkie nazwy kolumn w GROUP BYklauzuli jak poniżej. Zobacz różnicę składni. Musisz mieć wiedzę na temat wszystkich nazw kolumn, aby użyć GROUP BYklauzuli w takim przypadku.

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 |
+------+--------+------+

Zauważyłem również, że GROUP BYdomyślnie wyświetla wyniki w kolejności rosnącej, co DISTINCTnie. Ale nie jestem tego pewien. Może się różnić od dostawcy.

Źródło: https://dbjpanda.me/dbms/languages/sql/sql-syntax-with-examples#group-by

Zasadniczo możemy użyć DISTINCTdo wyeliminowania duplikatów w określonej kolumnie w tabeli.

W przypadku „GROUP BY” możemy Zastosuj funkcje agregujące jak AVG, MAX, MIN, SUM, iCOUNT na określonej kolumnie i pobrać nazwę kolumny i agregacja wynik funkcji na tej samej kolumnie.

Przykład:

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

Nie ma istotnej różnicy między klauzulami grupującymi i odrębnymi, z wyjątkiem użycia funkcji agregujących. Oba można wykorzystać do rozróżnienia wartości, ale jeśli z punktu widzenia wydajności grupa jest lepsza. Gdy używane jest odrębne słowo kluczowe, wewnętrznie korzystano z operacji sortowania, którą można wyświetlić w planie wykonania.

Spróbuj prostego przykładu

Deklaracja tabeli @tmpresult (Id tinyint)

Wstaw do @tmpresult Wybierz 5 Połącz wszystkie Wybierz 2 Połącz wszystkie Wybierz 3 Połącz wszystkie Wybierz 4

Wybierz odrębny identyfikator z @tmpresult