uzasno spor obican select upit , tabela 1GB sa 700000 redova

[apash86]

moze i tako ali opet to samo malo skracuje vreme u zavisnosti gde je taj ID jel na pocetku ili pri kraju tabele

resio sam da cu ici ipak sa
WHERE record_num >698745 AND record_num <698835 , pa neka bude poneka rupa, nema ih vise od 400-500, a to je zanemarljivo

ali sad ostaje veci problem, sta sa fulltext pretragom?

SELECT record_num,title, (MATCH (title,keywords) AGAINST ('interracial' IN BOOLEAN MODE)) as score FROM content WHERE MATCH (title, keywords) AGAINST ('interracial' IN BOOLEAN MODE) HAVING score > 0 ORDER BY content.record_num DESC LIMIT 456859,36

ovde moram koristiti LIMIT , ne znam kako drugacije?

[miks]

Originalno napisao apash86

...
resio sam da cu ici ipak sa
WHERE record_num >698745 AND record_num <698835 , pa neka bude poneka rupa, nema ih vise od 400-500, a to je zanemarljivo

ali sad ostaje veci problem, sta sa fulltext pretragom?



ovde moram koristiti LIMIT , ne znam kako drugacije?

Probaj sa

   ... WHERE record_num >698745 LIMIT 36

sa ovim nebi trebalo da ima rupa.

[dinke]

@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