Jeg så følgende MySQL-spørring som bruker både DISTINCT og GROUP BY sammen: 

SELECT DISTINCT user_id, post_id, post_content FROM some_table GROUP BY post_id, user_id HAVING post_content LIKE "%abc%";

Her er et scenario som følger med spørringen: Hver bruker har en unik id, user_id, og kan lage flere innlegg som identifiseres av en unik id, post_id. Hvert innlegg inneholder tekst.

Jeg syntes dette var forvirrende (etter å ha kommet fra Oracle DBs) og hadde spørsmålene nedenfor:

  1. Hva er meningen med å bruke GROUP BY uten å gjøre noen aggregering?
  2. Hva er betydningen av å bytte rekkefølgen på kolonnene i SELECT vs i GROUP BY ?
  3. Hva er meningen med å utelate den tredje kolonnen fra GROUP BY?
  4. Hvorfor er DISTINCT brukt sammen med GROUP BY? Kjører distinkt operasjon etter at alle grupperingene er gjort på det endelige resultatet eller før?

Kommentarer

  • Punkt 2: Det er ingen betydning. GROUP BY betyr ikke noe i det hele tatt (bortsett fra at det i gamle versjoner antydet det samme ORDER BY. SELECT rekkefølge er viktig bare i ordningen av kolonner i utdataene.

Svar

annonse 1) Gamle mysql-databaser, og når du deaktiverer KUN_FULL_GROUP_BY , kan du gjøre dette spørsmålet, og hvis post_innholdet er like, vil du legge merke til at mysql leverer en tilfeldig ikke deterministisk verdi tilbake .

annonse 2) ingen som helst

annonse 3) lat programmering og det oppstår en feil når du aktiverer ONLY_FULL_GROUP_BY

annonse 4) Nei, det vil vise alt post_innhold som er koblet til user_id, post_id som addind post_content til gruppen av

Som Strawberry allerede sa, spør ikke dette spørsmålet gir mening

Svar

Den vanvittige muligheten til å tillate delvis gruppering i eldre versjoner av MyS QL, må være en av de beste konkurrentene for mest forårsaket forvirring i IT-bransjen.

Gitt tabellen: 

CREATE TABLE t ( x int not null primary key , y int not null ); INSERT INTO t (x,y) VALUES (1,1),(1,2);

Uttalelsen 

SELECT x, y FROM t GROUP BY x

kan bety (1,1) eller (1,2) og MySQL vil tilfeldigvis returnere en av disse. DISTINCT spiller ingen rolle i dette tilfellet, resultatet er fremdeles in-deterministisk.

SQL92 krevde at alle kolonnene i valgt ledd (unntatt aggregerte kolonner og konstanter) er en del av GROUP BY-setningen.

SQL99 løsnet denne begrensningen litt og tillot oss å utelate kolonner fra GROUP BY som er funksjonelt avhengige av de gjenværende kolonnene. Dvs. 

CREATE TABLE t ( x int not null primary key , y int not null ); SELECT x, y FROM t GROUP by x

vil være gyldig siden y er f.d. av x

Overraskende nok (for meg) er nyere versjon av MySQL best i klassen når det gjelder implementering av SQL99-versjonen. Jeg har ikke sjekket det i det siste, men da jeg gjorde MySQL, håndterte jeg ganske kompliserte scenarier godt, der PostgreSQL bare håndterte trivielle.

Å svare på spørsmålene dine

1) 

SELECT x, y FROM t GROUP BY x, y

betyr at kombinasjonen av x, y er en gruppe. I alle mulige situasjoner kan jeg tenke på at dette er det samme som: 

SELECT DISTINCT x, y FROM t

Siden de blir logisk evaluert til forskjellige tider, kan det være noen hjørnesak der de faktisk ville være forskjellige (jeg kan ikke tenke på en skjønt)

2) Ingen , i denne forbindelse er de et sett med kolonner, så det er ingen rekkefølge

3) Se ovenfor.

4) Den logiske rekkefølgen for evaluering av et SQL-spørsmål er: 

FROM, JOIN WHERE GROUP BY HAVING SELECT DISTINCT ORDER BY FETCH FIRST

så GROUP BY skal evalueres før DISTINCT. Jeg kan ikke tenke på en situasjon der dette ville ha betydning.

I spørsmålet ditt Jeg mistenker at noen fikk forvirrende resultater, og prøvde å få et nytt resultat ved hjelp av DISTINCT. De var sannsynligvis heldige (eller uheldige) for å få det resultatet de forventet, så DISTINCT ble. Feilen er der fremdeles

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *