20 SQL užklausų prieš vieną!

Optimizavimo lenktynės - prie starto linijos stovi šios dvi gražuolės:

<?
for ($i=0; $i<20; $i++) $q = mysql_query("SELECT * FROM table WHERE primary_key = '$i'");
?>

ir

<?
for ($i=0; $i<20; $i++) $a[] = $i;
$q = mysql_query("SELECT * FROM table WHERE primary_key IS IN (" . implode(",", $a) .")");
?>

Nesigilinkim į sintaksės klaidas ir panašius netikslumus ;) Esmė yra kuri iš šių greitesnė (edit:o galbūt "lengvesnė" duomenų bazei? galbūt "užlockina" trumpesniam laikui?).. Atsiprašau, kad tingėjau pats testintis, bet dabar kitais reikalais užimtas, o smalsumas nuvedė tik iki forumo pasiklaust ;)

Sorry, is pradziu neisigilinau i syntaxe. As uz 2 varijanta ;) Vis del to kur 20 queriu, kur 1.

Su daug queriu galinčios kilti problemos:

1. Užklausų limitas serveryje (jei nustatyta - kai kurie hostingai mėgsta ribot užklausų kiekį) - greit išnaudosi

2. Ilgiau trunkantis duomenų perdavimas tarp mysql serverio ir script'o ("siunti, gauni, siunti, gauni, siunti, gauni [....]" vs. tik vienas siunti-gauni).

3. Mysql'ui gali nusiboti būti išnaudojam kaip laisvo elgesio mergina.. pasidarysi bottle neck'ą čia. Turėtų pasijausti, kai bus daug lankytojų vienu metu - kai tiek daug užklausų keliaus, jų vykdymas lėtės, kol galiausiai susilauksi "too many connections", o mysql'as nueis pailsėt keikdamasis ir pykdamas ant tavęs.

Jei IN buvo sukurtas, kad išvengti tokių dalykų kaip didelis kiekis užklausų, tai ko dabar spjauti į veidą kūrėjams ir daryti priešingai, negu jie siūlo ;)

Aišku galbūt kai kuriais atvejais keli queriai veiktų greičiau, negu vienas, tačiau benchmarkinant reiktų pažiūrėt kaip reaguotų su daug connectionų vienu metu.

Patariu įsidiegti kokį benchmarkinimo įrankį (linuxuose po defaultu ab (apache bechmark) komanda veikia tam - labai patogu), nes ne visada viskas veikia taip kaip tikimasi ar kaip parašo forumų lankytojai - negali žinot kokia ten lentelių struktūra pas žmogų ir daug kitų niuansų.

P.S. gali tekti pasiredaguot mysql configuraciją, jei labai jau ilga užklausa bus (daug visko po IN). Bet paprastai užtenka nustatytų limitų.

man atrodo db apkraunama yra maziau kai kuo maziau yra query... o del pacio veikimo scripto, tai kuris greiciau suksis tiksliai pasakyti negaliu, bet ciuju tas kur maziau queriu. nors nesu tikras... ;)

Keli queriai serveriui visada yra blogesnis variantas nei vienas. Jei desktop aplikacijai dar butu galima izvelgti prasme skaidyti querius i atskirus, tai web aplikacijai tas visiskai netinka del jau kolegu minetu priezasciu.

Kitais zodziais - leisk DB serveriui paciam susioptimizuoti. Kita vertus IN yra labai jau sudetingas "veiksmas", kadangi tai yra tik kitas budas aprasyti OR salyga. Sudetingas tuo, kad paprastai nebera kaip panaudoti indeksus. Suprantu kad sitie SQL yra is lempos, bet siulau paieskot rimtesniu galimu salygu, jei labai norisi optimizacijos.

Tiesiog galima pamineti, tai, kad jeigu 20 Queriu, mysql tures 20 kartu scanuoti visa lenta. Bet vat antrame varijante neaisku, ar Indexus panaudos, ar eis scanavimas per visa lenta, kas labiausiai tiketina, o jeigu duomenu bus daug, tai bus labai blogai. Realiai, galetum su ciklu sugeneruoti sql, kuriame sudetum OR salygas ir sitaip pratikrintum ar yra tas elementas ar ne.

Tiesiog galima pamineti, tai, kad jeigu 20 Queriu, mysql tures 20 kartu scanuoti visa lenta. Bet vat antrame varijante neaisku, ar Indexus panaudos, ar eis scanavimas per visa lenta, kas labiausiai tiketina, o jeigu duomenu bus daug, tai bus labai blogai. Realiai, galetum su ciklu sugeneruoti sql, kuriame sudetum OR salygas ir sitaip pratikrintum ar yra tas elementas ar ne.

Is xdvx atsakymo kilo man tokia ideja pasiulyt toki sprendima (cia tik jeigu ieskoma pagal primary_key ir jo reiksmes nera einancios paeiliui):

SELECT * FROM table WHERE primary_key = $a[0]
UNION
SELECT * FROM table WHERE primary_key = $a[1]
UNION
SELECT * FROM table WHERE primary_key = $a[2]
UNION
SELECT * FROM table WHERE primary_key = $a[3]
.....

Siuo atveju 100% yra panaudojamas primary_key indeksas ir tera tik 1 uzklausa. Kaip jau minejau OR (tuo paciu ir IN) atveju, indeksai dazniausiai nepanaudojami (BET sita nuomone paremta MS SQLServer, gali but kad MySQL kiek kitaip su tuo tvarkosi).

Bet realiai sitaip manau tas pats kas 20 queriu atskirai, bent mano supratimu. O kodel sakai OR nepanaudoja? Nekarta teko dirbti su milziniskom lentom, kurios sieke kelis gigabytus, ir nevienas queris su OR. Jeigu indexu nebutu naudojes MySQL servas su tokiais queriais ant tokiu lentu butu uzsivertes

Na as taip pat manau kad UNION tikrai nera optimaliausias variantas.

Bet realiai sitaip manau tas pats kas 20 queriu atskirai, bent mano supratimu. O kodel sakai OR nepanaudoja? Nekarta teko dirbti su milziniskom lentom, kurios sieke kelis gigabytus, ir nevienas queris su OR. Jeigu indexu nebutu naudojes MySQL servas su tokiais queriais ant tokiu lentu butu uzsivertes

nope. ne tas pats. cia yra vienas queris. kas vyksta jau serverio viduj yra kitas reikalas. Prisegu jums pvz kaip dirba SQL serveris (gaila MySQL neturiu tokiu toolsu, butu idomu paziuret).

beje T-Mix, toks patarimas - dirbant su DB serveriu reikia mastyt ne kaip tu tai supranti, o kaip tai supranta serveris. Yra galybe situaciju, kur zmogus pasielgtu vienaip, o serveris optimizaciju ir savo vidines strukturos vedamas pasielgia visai kitaip.

EDIT: dar toks pastebejimas, kadangi salygoje naudojamas stulpelis, kuris visada skiriasi, todel galima naudot UNION ALL vietoj UNION. To pasekoje is execution plano pasalinamas "Sorting" veiksmas ir to rezultate apkrovos pasiskirstymas is 51/49 % pasidaro 60/40 %.