|
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 |
08. 11. 2011. | #11 |
Super Moderator
Invented the damn thing
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
701 "Hvala" u 194 poruka
|
Mozes da smanjis record_num polje sa big int na neki manji int, a ostala int polja ako da takodje korigujes u skladu sa vrednostima koje se trebaju unositi.
Takodje za order je neophodan index, tako da ga moras kreirati (record_num polje), trenutno ga nemas. |
08. 11. 2011. | #12 | |
član
Na probnom radu
Datum učlanjenja: 08.07.2008
Lokacija: Jagodina
Poruke: 42
Hvala: 0
4 "Hvala" u 4 poruka
|
tu je index nego 10puta sam brisao sve indexe i optimizovao bazu. skratio sam bigint i ostale int/varchar/text polja na minimum ali opet sve isto, pvi put za upit treba i vise od 100sec, dok svaki sledeci radi ispod 1s
evo i config od mysql, mislim da je i on ok Citat:
instalirao sam sad sphinx pa cu videti da kroz njega ide pretraga, posto stvarno vise nemam ideju sta da radim |
|
08. 11. 2011. | #13 |
Nikola Denić
Sir Write-a-Lot
|
bolje probaj Apache Lucene ...
__________________
Do not ask yourself what the world needs. Ask yourself what makes you come alive, and then go do that. Because what the world needs is people who have come alive |
08. 11. 2011. | #14 |
član
Na probnom radu
Datum učlanjenja: 08.07.2008
Lokacija: Jagodina
Poruke: 42
Hvala: 0
4 "Hvala" u 4 poruka
|
cini mi se da je lighttpd server
jedno brzinsko pitanje, ako je "record_num" primary key, onda on nema potrebe da se opet definise kao index?! |
08. 11. 2011. | #15 |
Super Moderator
Invented the damn thing
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
701 "Hvala" u 194 poruka
|
nema potrebe, sorry nisam video gore da ti je record_num zapravo primary key.
|
08. 11. 2011. | #16 |
Banned
Knowledge base
Datum učlanjenja: 01.07.2005
Poruke: 1.598
Hvala: 206
140 "Hvala" u 89 poruka
|
@dinke
Da li si siguran da definisana velicina polja u mysql-u (i vecini drugih db) ima bilo kakav uticaj na brzinu ? Koliko sam ja upucen signed pretpostavlja vrednosti od -2147483648 do 2147483647, a unsigned 0 do 4294967295. Mozda gresim ali zar nije velicina polja tu samo radi validacije pri unosu i slicnih stvari ? |
08. 11. 2011. | #17 | |
član
Certified
Datum učlanjenja: 24.02.2009
Poruke: 55
Hvala: 0
11 "Hvala" u 7 poruka
|
Citat:
Kôd:
... WHERE record_num >698745 LIMIT 36 |
|
08. 11. 2011. | #18 |
Super Moderator
Invented the damn thing
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
701 "Hvala" u 194 poruka
|
@cvele
Siguran sam, naravno Za pocetak manual oko numerickih tipova: http://dev.mysql.com/doc/refman/5.5/...ric-types.html Kao sto vidis int koristi 4 bajta za smestanje, bigint koristi celih 8. Ukratko za istu kolicinu podataka zauzeces duplo veci broj podataka na hdd-u. Veca tabela = sporija tabela, sporiji indeksi itd. Za vise detalja mysql manual http://dev.mysql.com/doc/refman/5.5/en/data-size.html Inace isto vazi i sa ostale fiksne tipove (npr char), premda opet stvari nisu crno bele, char je brzi za pretrazivanje od varchara ali da ne sirim pricu |
08. 11. 2011. | #19 | ||
expert
Grand Master
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
959 "Hvala" u 153 poruka
|
Citat:
Citat:
|
||
08. 11. 2011. | #20 |
član
Na probnom radu
Datum učlanjenja: 08.07.2008
Lokacija: Jagodina
Poruke: 42
Hvala: 0
4 "Hvala" u 4 poruka
|
|
|
|