Láttam a következő MySQL lekérdezést, amely a DISTINCT és a GROUP BY együtt is használja: 

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

Itt van egy forgatókönyv a lekérdezéshez: Minden felhasználó egyedi azonosítóval rendelkezik, user_id, és több bejegyzést is készíthet, amelyeket egyedi azonosítóval azonosít, post_id. Minden bejegyzés tartalmazna szöveget.

Ezt zavarónak találtam (miután az Oracle DB-kről érkeztem), és az alábbi kérdések merültek fel bennem:

  1. Mit jelent a GROUP BY összesítés nélkül?
  2. Mi a jelentősége az SELECT és az GROUP BY oszlopok sorrendjének átkapcsolásának? ?
  3. Mit jelent a harmadik oszlop kihagyása a GROUP BY részből?
  4. Miért van az DISTINCT a GROUP BY paranccsal együtt használható? Különálló művelet fut, miután az összes csoportosítást elvégezték a végeredményen vagy azt megelőzően?

Megjegyzések

  • 2. tétel: Nincs jelentőség. A GROUP BY egyáltalán nem számít (kivéve, hogy a régi verziókban ugyanezt ORDER BY jelentette. A SELECT a sorrend csak a kimenet oszlopainak elrendezésében számít.

Válasz

1. hirdetés) Régi mysql adatbázisok, és amikor letiltja a ONLY_FULL_GROUP_BY funkciót, akkor megadhatja ezt a lekérdezést, és ha a post_content értéke egyenlő, észreveheti, hogy a mysql véletlenszerű, nem determinisztikus értéket ad vissza .

ad 2) semmi, ami így van

ad 3) lusta programozás, és hiba lép fel, ha engedélyezi a ONLY_FULL_GROUP_BY

ad 4) Nem, minden olyan post_content megjelenik, amely a user_id, post_id elemhez kapcsolódik, hasonlóan a post_content hozzáadásához a csoporthoz. bármilyen értelme van

Válasz

Az az őrült képesség, hogy részleges csoportosítást engedélyezzen a MyS régebbi verzióiban. A QL-nek az egyik legfontosabb versenyzőnek kell lennie az it-iparban leginkább okozott zavarban.

A táblázat: 

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

A kijelentés 

SELECT x, y FROM t GROUP BY x

jelentheti (1,1) vagy (1,2), és a MySQL véletlenszerűen adja vissza az egyiket. A DISTINCT ebben az esetben nem számít, az eredmény továbbra is determinisztikus.

Az SQL92 megkövetelte, hogy a select tagmondat összes oszlopa (az összesített oszlopok és konstansok kivételével) a GROUP BY záradék része legyen.

Az SQL99 kissé lazította ezt a korlátozást, és lehetővé tette számunkra, hogy kihagyjunk a GROUP BY oszlopokat, amelyek funkcionálisan függenek a többi oszloptól. Vagyis 

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

érvényesek lennének, mivel y f.d. az x

Meglepő módon (számomra) a MySQL későbbi verziója a legjobb az osztályban, amikor az SQL99 verziót kell bevezetni. Mostanában nem ellenőriztem, de amikor csináltam, a MySQL jól kezelte a meglehetősen bonyolult forgatókönyveket, ahol a PostgreSQL csak apróságokat kezel.

A kérdések megválaszolásához

1) 

SELECT x, y FROM t GROUP BY x, y

azt jelenti, hogy az x, y kombinációja csoport. Ez minden lehetséges helyzetben ugyanolyan, mint: 

SELECT DISTINCT x, y FROM t

Mivel logikailag különböző időpontokban értékelik őket, előfordulhat, hogy vannak olyan sarok esetek, ahol valójában különböznének (nem tudok ilyesmire gondolni)

2) Nincs , ebben a tekintetben oszlopokból állnak, tehát nincs sorrend

3) Lásd fent.

4) Az SQL lekérdezés kiértékelésének logikai sorrendje: 

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

tehát a GROUP BY-t állítólag ki kell értékelni a DISTINCT előtt. Nem tudok olyan helyzetre gondolni, ahol ez számítana.

A lekérdezésben Gyanítom, hogy valaki zavaros eredményeket ért el, és megpróbált újabb eredményt elérni a DISTINCT használatával. Valószínűleg ott van a szerencséjük (vagy várható, így a DISTINCT maradt. A hiba továbbra is fennáll.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük