MySQL - Dolgi query ali več manjših?
10 naročnikov
10 naročnikov
Zanima me ali se je boljše potruditi in narediti en "dolgi" query v katerem uporabiš JOIN-e ali je vseeno in pač narediš več manjših, ko kakšen podatek potrebuješ? Predvsem me zanima z vidika hitrosti (za končnega uporabnika) in obremenitve (za strežnik)?
22 odgovorov
V primeru, da uporabljaš join, si poglej tale primer:
Povezuješ 3 tabele (recimo x, y in z). V x tabeli imaš 1000 zapisov, v y tabeli imaš 5000 zapisov, v z tabeli imaš 500 zapisov. Join najprej dejansko primerja vsakega z vsakim in dobiš 2.500.000.000 vrstic (10005000500). To so zaenkrat še nekakovostni podatki. Šele nato pa se izvede "on" del stavka ( ... join on x.idx = y.idx) ter recimo dobiš 2.500 vrstic s pravimi podatki. (kar pomeni, da mora baza pogledat pri vsaki vrstici ali se "on" del stavka ujema: Razmerje podatkov v tem primeru je 1:1.000.000=kakovostni:nekakovostni).
+ 1 kompleksen sql stavek
- ogromno dela za procesor in podatkovno bazo
Če narediš več manjših:
+ manj dela za procesor in podatkovno bazo
- več sql stavkov (za vsako bazi pošlješ sql stavek, baza ga obdela, ga vrne nazaj, na vrsti je drug stavek itd.)
Na kratko: za delo z večjo količino podatkov je join počasnejši in bolj obremeni mašino.
Se motim?
Ja odvisno kako dolg je ta query, če je res 150 joinov potem je res bolje, da delaš posamezne selecte, če pa imaš le par joinov pol pa je povezovanje, kopiranje podatkov (iz mysql v mysql driver (pred php 5.3)) za vsak select posebej pomoje počasnejše.
Zadeva torej zavisi od količine podatkov.
schtr4jh, kakšne neumnosti pa govoriš, madona? Še nikoli nisi slišal za indekse? :)
G-force, načeloma bi moral biti en query hitrejši že zaradi tega, ker imata query parser in query optimizer delo le enkrat. Kaj točno je pa v tvojem primeru hitrejše, pa rajši stestiraj :) Če pa res potrebuješ veliko količino manjših (enakih) queryjev, si pa oglej prepared statements.
Sicer z SQL že dolgo nisem delal, sem pa slišal ravno zadnjič eno anekdoto, ki ti bo mogoče odgovorila.
V eni večji spletni banki so imeli grozen problem s počasnim queryem, ki se je izvajal 20+ sekund; nesprejemljivo. In to na grozno hitrih mašinah - gre se za okolje kjer denarnih omejitev ni.
No, najeli so enega DB admina, ki jim je v nekaj uricah poslal nazaj ostudno dolg SQL stavek, ki je vrnil željeni rezultat v 20ms :)
:)
ps. šlo se je pa za MS SQL.
Samo da ne bomo na koncu izvedeli, da gre za bazo s 12 tabelami od katerih bi bil join na 2 tabeli in da nobena nima več kot 500 vrstic v tabeli :) in da je 50 obiskov na dan :)
G-force, da se fantje ne bi matrali... lahko poveš kak podatek več?
Vini:
schtr4jh, kakšne neumnosti pa govoriš, madona? Še nikoli nisi slišal za indekse? :)
Najverjetneje sem nekaj pojmov pobrklal ampak vseeno se mi dozdeva, da nam je profesor povedal, kaj se zgodi, ko uporabljamo join stavke. Možno, da je zraven rekel, da se to zgodi, če ne uporabljamo indexov. =) (zato sem pa zraven dodal "Se motim?") =)
Dolg SQL stavek? Meja je kaj 22" monitor, preden se vrstica zlomi?
Tak o vprašanju če ti ne gre join, ali je smiselno delat join ali pa enostavno en SQL stavek, kjer izbiraš iz a in b tabele, na podlagi a.id in b.nek_id = a.id iz tabele a in tabele b. Spada ta stavek pod dolge ker ni joina? :D
Primer za zadnji post v phpBB3 v nekem forumu oz. sklopu:
SELECT t.topic_id, t.topic_title, t.topic_last_post_id, t.forum_id, p.post_id, p.poster_id, p.post_text, p.post_time, u.user_id, u.username, a.topic_id, a.attach_id
FROM $table_topics t, $table_forums f, $table_posts p, $table_users u, $table_attachments a
WHERE t.topic_id = p.topic_id AND
f.forum_id = t.forum_id AND
t.forum_id = 2 AND
t.topic_status <> 2 AND
p.post_id = t.topic_last_post_id AND
p.poster_id = u.user_id AND
a.topic_id = p.topic_id
ORDER BY p.post_id DESC LIMIT $topicnumber";
Pa stvar dela normalno, pa ni moje stvarjenje, bi se sam verjetno kakega joina lotu, bi bil pa verjetno daljši :D
@carli, tvoj stavek je slab. boljši, hitrejši (v navezi z indexi) in nič daljši bi bil, če bi uporabil JOIN :)