Mysql optimalizácia - join , group by – MySQL – Fórum – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama
Reklama

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

 

Hledá se programátor! Plat 1 800 € + bonusy (firma Boxmol.com)
jatt0
Newbie
31. 7. 2010   #1
-
0
-

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


Explain produkuje nasledovnú tabuľku:
1 PRIMARY <derived2> ALL NULL NULL NULL NULL 21 Using temporary; Using filesort
1 PRIMARY u eq_ref PRIMARY,uzivatel_id PRIMARY 4 a.uzivatel_id 1
2 DERIVED jfw_pict ALL NULL NULL NULL NULL 21 Using temporary; Using filesort

s čím samozrejme nie sme spokojný ... skúšal som už rozne alternatívy indexov ako aj iné rôzne query ... googlil som jak blbec ale k ničomu som sa nedostal..... Vopred ďakujem za akékoľvek myšlienky...

Nahlásit jako SPAM
IP: 81.43.159.–
Reklama
Reklama
KIIV+42
God of flame
31. 7. 2010   #2
-
0
-

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

Nahlásit jako SPAM
IP: 77.237.136.–
Program vždy dělá to co naprogramujete, ne to co chcete...
jatt0
Newbie
31. 7. 2010   #3
-
0
-

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

Nahlásit jako SPAM
IP: 81.43.159.–
KIIV+42
God of flame
31. 7. 2010   #4
-
0
-

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)

Nahlásit jako SPAM
IP: 77.237.136.–
Program vždy dělá to co naprogramujete, ne to co chcete...
jatt0
Newbie
31. 7. 2010   #5
-
0
-

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

Nahlásit jako SPAM
IP: 81.43.159.–
KIIV+42
God of flame
31. 7. 2010   #6
-
0
-

To jatt : proste experimentuj

Nahlásit jako SPAM
IP: 77.237.136.–
Program vždy dělá to co naprogramujete, ne to co chcete...
remmidemmi0
Super člen
2. 8. 2010   #7
-
0
-

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.

Nahlásit jako SPAM
IP: 84.244.81.–
jatt0
Newbie
6. 8. 2010   #8
-
0
-

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

Nahlásit jako SPAM
IP: 81.43.159.–
remmidemmi0
Super člen
8. 8. 2010   #9
-
0
-

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. :)

Nahlásit jako SPAM
IP: 84.244.81.–
Zdeny
~ Korektor
0
Grafoman
12. 8. 2010   #10
-
0
-

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í.

Nahlásit jako SPAM
IP: 88.102.243.–
www.devtea.cz | zdenekvecera.cz | @ZdenekVecera
Redaktor Programujte.com a Živě.cz
Zjistit počet nových příspěvků

Přidej příspěvek

Toto téma je starší jak čtvrt roku – přidej svůj příspěvek jen tehdy, máš-li k tématu opravdu co říct!

Ano, opravdu chci reagovat → zobrazí formulář pro přidání příspěvku

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:

×Vložení videa

Aktuálně jsou podporována videa ze serverů YouTube, Vimeo a Dailymotion.
×
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo emailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové příspěvky (pouze pro přihlášené)
Sleduj vlákno a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.
Reaguješ na příspěvek:

Uživatelé prohlížející si toto vlákno

Uživatelé on-line: 0 registrovaných, 11 hostů

Podobná vlákna

Optimalizacia MySQL — založil Flowy

Optimalizácia tabuľky — založil Majo

Optimalizacia pre IE 5.5 — založil greppi

PHP optimalizácia/Cache — založil Anonym

 

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032016 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý