2010/11/5 Quamis <[email protected]>: > Ca sa iau pic si partea programatorului... > ORDER BY RANDOM() e perfect legal si rapid:)
Pentru anumite valori ale lui legal si anumite valori ale lui rapid... > Problema e ca nu face cache, dar nici asta nu cred ca e o problema asa > mare, din moment ce smecheria asta se intampla fara sa se atinga de > disk(tabelul e in memorie, doar il sorteaza altfel). Daca tabelul e suficient de mic, sau memoria suficient de multa. > Sistem quad core e cam degeaba, din cate stiu se tot incearca sa se > faca mysql-ul sa ruleze multiprocesor, nu stiu daca au ajuns prea > departe, dar pana una-alta mysql-ul e un singur thread, in mare parte > disk-bound. Si sincer, din moment ce "clientul" vrea sa aiba pe prima > pagina articole alese aleator din baza de date... is there another > way? Da. > clientul e cel care plateste quad-core-ul, clientul e cel care > plateste si programatorul, clientul e cel care in final are de > pierdut... > E treaba programatorului sa implementeze eficient ce are _de fapt_ nevoie clientul, nu doar sa traduca din romana in php. Daca programatorul decide sa faca ce vrea clientul, sa-i ia banii si sa-si ia picioarele la spinare, n-are decat, dar sa nu faca pe mironosita dupa aia. > Mai zicea cineva de "SELECT SQL_CALC_FOUND_ROWS, etc FROM". Asta e > varianta optimizata. Intern nu stiu ce face, si in manual nu scrie > nimic, nu stiu de unde tragi concluzia asta. "Mie nu mi-a zis nimeni, deci n-am nici o vina". > Daca e asa, mi se pare o > problema majura a serverului, nu a programatorului, dar din ce teste > am facut eu, un select cu SQL_CALC_FOUND_ROWS e mult mai rapid decat > SELECT cu LIMIT si apoi sa faci inca unul fara LIMIT... Oricum, alta > metoda sa afli numarul de randuri nu prea ai. > Mai ai, trebuie doar sa-ti pese. As zice sorry de flama, da' e vineri si ce pana mea. -- Petre. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
