Mysql optimalizácia - join , group by – MySQL – Fórum – Programujte.com

Takže prajem príjemný deň a mám pre Vás jeden oriešok na rozlúsknutie...

Každý sme sa určite už stretli so situáciou kedy sme potrebovali vytiahnuť data z dvoch tabuliek ... jasné.
Takže jednoducho povedané potrebujem výpis použivateľov z jednej tabuľky a prideliť fotku z druhej...
Háčik? ... každý použivateľ má viac fotiek a ja ich chcem vyberať náhodne.

takže ....

SELECT u.*, a.fotka FROM uzivatelia u 

JOIN (SELECT fotka FROM fotky ORDER BY RAND()) a

ON u.uzivatel_id = a.uzivatel_id 

GROUP BY uzivatel_id

ORDER BY uzivatel_registracia

umis si neco takoveho predstavit u 1000 uzivatelu kazdej s treba 100 fotkama?

z jakeho duvodu to nemuzes udelat pomoci dvou dotazu? vytahnout treba 10 uzivatelu a k nim pak vytahat po jedne fotce?

Edit: abych to shrnul
- nepracuj s celejma tabulkama WHERE s indexama umi zazraky
- zbytecne nespojuj (a jeste cele tabulky)
- doufam ze "fotka" neni cela fotka v databazi .. (staci vytahnout nazev nebo id a predat jinemu scriptu, ktery ji zobrazi - na to staci jeden dotaz a dobrej index)
- pokud to jde tak se da resit nahodna fotka ciste tim scriptem pro jeji zobrazeni .. tj. zadny joiny nejsou potreba..
a tak dale

To KIIV :
- Jasné ... nie je podstatné či sa jedná o fotky alebo iné data či text ... samozrejme uchovávaš názvy a nie celé fotky.
- ten dotaz je príklad nie konkrétna situácia

Ak to chápem správne .... podľa toho čo si mi napísal je výhodnejšie 1001 dotazov ako jeden dotaz s JOIN ... ???

Práve toto ma zaujíma ... samozrejme že jednoduchý dotaz s dobrým indexom je najlepší ale ak je napríklad 1000 užiaveteľov tak to máš 1000 dotazov na jedno zobrazenie ....

Samozrejme sa bavíme v teoretickej rovine a jedná sa mi o opitmalizáciu... (nie diskusiu koľko uživateľov vypíšem na stránku, či vyťahujem veľké data a či menšie a tak podobne... )

dík za odpoveď... čakám ďalšie rady...

To jatt : co ti brani to zjistit.. udelej dve tabulky.. v jedne mej 1000 zaznamu a ve druhe pro kazdej zaznam 1000 polozek (samozrejme index nad klicema)

udelej join tak jak si ho napsal (tj. spojit komplet vsechny data)
udelej join s tim, ze vyberes jen jedno ID a k nemu vsechny polozky pripojene
udelej to na jednotlive dotazy..

osobne neznam moc pripadu kdy je potreba pracovat s celou tabulkou

EDIT: tak to trochu testuju a ten dotaz co si dal je zatim naprosto nejpomalejsi ze vsech moznosti.. pres 25s na 1000x1000000 zaznamu..
kdyz sem dal aspon: SELECT * FROM `t1` join (SELECT * From t2 WHERE t1id = 999 ORDER BY rand() ) tt on (t1.id = tt.t1id)
where t1.id = 999; tak se doba zkratila na cca 0.0386

dokonce SELECT * FROM `t1` join t2 on (t1.id = t2.t1id)
where 1 mi trva nejak podezrele kratce.. asi uz je to v cache (a to poprve zabralo asi 0.25s)

To KIIV : Je mi jasné že pokial nepridám správne indexy pre JOIN nemá zmysel to skúšať ... je jasné že dva krát použitie: Using temporary; Using filesort zabere veľa času ... Moja pôvodná otázka nebola či je jednoduchý dopyt x 1000 rýchlejší ako 1 x JOIN ale či je možné nejak zindexovať GROUP BY, nakoľko jednoduchý JOIN so správnymi indexami je určite rýchlejší ako dva jednotlivé dotazy, ale tu sa jedná o RAND a GROUP BY...
Už pri jednoduchom dotaze s RAND máš problém...

Je samozrejme že pokiaľ sa jedná o konkrétnu situáciu hodíš pri výpise na stránku LIMIT 10 a už je to len 11 jednoduchých dotazov ... neviem len my to príde také nejaké neohrabané ... chcel som radu od skúsenejších

dík ....

To jatt : proste experimentuj

V prve tabulce mas seznam uzivatelu a u kazdeho uzivatela kolik (pocet) ma fotek v druhe tabulce.. Tak 1. krok vyber uzivatela.
V druhe tabulce mas odkazy na fotky (ID fotek) a ID uzivatele (komu ta fotka vlastne patri). Ve druhem kroku vygeneruj nahodne cislo vetsi nez 1 a menzi nez pocet fotek uzivatele vybraneho v prvem kroku. To nahodne cislo bude ID fotky. Tak z druhe tabulky vuber ten zanam, aby se shodoval s ID uzivatele a cislem fotky.

To remmidemmi : Jasné dík za odpoveď .. Programovo viem čo mám urobiť ak sa jedná o dva nezávislé dotazy ... išlo mi konkrétne optimalizáciu a JOIN, RAND ...

Dík za odpoveď .. zatiaľ to rieším cez viac dotazov... Ak bude mať niekto návrh na optimalizáciu a riešenie cez jeden dotaz určite si to rád pozrem... Dík

Jeden složitý komplexní dotaz může být mnohem víc naročnější i po optimalizaci, než pár jednoduchých dotazů bez oprimalizace. :)

To remmidemmi : Přesně tak. Navíc je třeba myslet na cache. Pokud je v (mega) dotazu RAND(), tak je to další hřebík do rakve - výsledek se neuloží do cache. Při rozdělení dotazu na menší kusy je větší pravděpodobnost, že se některé (bez RAND()) nacachují.