|
SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka |
|
Alati teme | Način prikaza |
22. 01. 2007. | #11 | |
Direktor Kombinata
Invented the damn thing
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
|
Citat:
PHP kôd:
__________________
activeCollab - Project Management and Collaboration Tool iz domaće kuhinje | area51.rs - Blog Poslednja izmena od Ilija Studen : 22. 01. 2007. u 21:25. |
|
22. 01. 2007. | #12 | |
Ivan Dilber
Sir Write-a-Lot
|
Citat:
u opstem slucaju da, ali u opstem slucaju ni join ne bi smeo da bude problem na indexiranim tabelama evo ovde jedan zanimljiv text gde se pominju i jedni i drugi slucajevi optimizacija: http://www.xaprb.com/blog/2006/04/30...oins-in-mysql/ zao mi je sto sam uvek lenj da zapisem negde kad naletim na tako nesto cudno, tako da sad nemam ni jedan primer, ali desilo mi se par puta da vidim tako neke skroz neocekivane rezultate...tako da ako vidis da je upit spor i da mora da se optimizuje, treba probati sve alternativne verzije pa videti sta je realno najbrze, posto su ponekad neke naizgled bezvezne stvari, potpuno nenadano, brze od skolskih resenja, a teporetski je to vrlo tesko predvideti..
__________________
Leadership is the art of getting people to want to do what you know must be done. |
|
23. 01. 2007. | #13 |
Ivan Dilber
Sir Write-a-Lot
|
evo iskopao sam u bookmarks jos jednu stranu sa lepim primerima: http://www.onlamp.com/pub/a/onlamp/2...m_clauses.html
[Edit ne radi posle 30 minuta, zato pisem posebnu poruku, sorry..]
__________________
Leadership is the art of getting people to want to do what you know must be done. |
23. 01. 2007. | #14 |
Boris
Grand Master
Datum učlanjenja: 01.12.2005
Lokacija: Novi Sad
Poruke: 775
Hvala: 5
156 "Hvala" u 2 poruka
|
Eksperimentisi dosta sa EXPLAIN, i uveri se da ti upiti koriste odgovarajuce indekse... Desilo mi se jednom da sam greskom napravio vise slicnih indeksa, pa je mysql koristio najgoru varijantu (ne secam se tacnog scenarija), ispalo je da je sporije sa indeksima nego bez indeksa. Naravno, uklanjanjem jednog suvisnog indeksa, sve je proradilo.
__________________
"It’s important to have goals when you pet. Otherwise you’re just rubbing another mammal for no reason." - Scott Adams |
23. 01. 2007. | #15 |
Super Moderator
Knowledge base
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
|
aj se vratite na temu, jer i mene interesuje
da li ce perfomanse biti slabije kod tabele koja ima manje polja u odnosu na tabelu koja ima vise polja? [a pri tome ne koristim ta polja za WHERE i ORDER, i polja su fixed-width]. da li postoji neki broj do koga broj polja nije problematican, a odakle vec pocinje da utice na perfomanse? prostije, da li ce tabela sa 10 i 100 polja imati iste perfomanse? [indeksi isti za obe tabele] |
23. 01. 2007. | #16 |
old school
Professional
|
Ako imas Data Warehouse bazu, onda ti je bolje imati jednu tabelu sa vise polja, nego nekoliko tabela sa manje polja, jer je tada full table scan brzi od visestrukog index lookup join-a (npr. star transformation join).
Ako imas OLTP bazu, onda ti je bolje imati tabele sa manje polja. Ako imas objekt sa vise atributa od kojih su samo par atributa kljucni, onda kreiraj dvije ili vise tabela: jednu manju sa kljucnim atributima (poljima) i jednu ili vise njih sa sekundarnim atributima, koje ces medjusobno povezati preko kljuceva. Mozes potom tu sekundarnu tabelu i kompresovati ukoliko ne radis cesto update na njoj, jer se pri selektovanju dobija na brzini. Nije dobro stavljati previse indexa na tabelu (tzv. overindexed table), jer se pri DML operacijama (INSERT, UPDATE i DELETE) usporava cijeli proces zbog aktualizovanja indexa. Pogotovo nakon ucestalog UPDATE-a ili DELETE-a pozeljno je uraditi rebuild indexa i OPTIMIZE tabele, jer se stvaraju rupe (gaps) izmedju zapisa. Uprkos dobro dizajniranoj strukturi baze, vecina programera napise lose i neperformantne upite, kojima usporavaju cijelu aplikaciju. U vecini slucajeva se prepravljanjem SQL upita moze puno dobiti na brzini. Osim toga, ako imas svoj server, mozes podesavati i konfiguracijske parametre (cache buffer, file-per-table, uraditi stripping tabela na vise hard diskova i td.). U svakom slucaju bez obzira sta kazu teorija i EXPLAIN PLAN, samo uzastopnim testiranjem i mijenjanjem postavki i SQL upita mozes doci do opipljivih rezultata.
__________________
Blog: Baze podataka ------------------------ Oracle OCP DBA Oracle OCE SQL Expert Oracle OCP Developer Certified MySQL DBA |
23. 01. 2007. | #17 | |
Ivan Dilber
Sir Write-a-Lot
|
Citat:
sa 10 i 10000 recorda nema neke bitne razlike. Ali za 3-4 miliona ima razlike, cak i na indexiranim poljima, jer indexi postanu glomazni. Preko 3-4 miliona recorda i 2GB velicine na disku nije zdravo raditi sa myISAM tabelama, to znam iz iskustva (za INNODB ne znam). Takodje joinovi na tako velikim tabelama pocnu da se vuku uzasno.. sto se broja kolona tice, tu su male razlike, mislim da ne pravi nikakvu razliku, sem ako napravis previse indexa sto usporava upis i izmene...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
|
23. 01. 2007. | #18 |
Vladan Zirojević
Grand Master
|
Nemam mjerenja, ali cini mi se da sam procitao da nije preporucljivo imati ni ogroman broj kolona (recimo 100+). I da to utice na performanse. Nisam probao, tako da pisem iz sjecanja...
|
|
|
Slične teme | ||||
Tema | Početna poruka teme | Forum | Odgovori | Poslednja poruka |
Dajte predlog rešenja - Photo voting community | istok | Web aplikacije, web servisi i software | 2 | 22. 01. 2009. 10:47 |
www.askeet.com - Web 2.0 servis od ideje do gotovog rešenja | Ilija Studen | PHP | 1 | 26. 12. 2005. 18:06 |
Jednostavan php album sa sledećim opcijama | mungos | PHP | 9 | 24. 06. 2005. 14:21 |