Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

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

[es] :: MySQL :: uzasno spor obican select upit , tabela 1GB sa 700000 redova

[ Pregleda: 2400 | Odgovora: 5 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Golja

Član broj: 92685
Poruke: 85
212.178.228.*



Profil

icon uzasno spor obican select upit , tabela 1GB sa 700000 redova07.11.2011. u 16:54 - pre 150 meseci
vise ne znam sta da optimizujem kad obican select traje i vise od minut, server je sa 8gb ram, mysql 5.1.58

tabela ima 700000rows

npr ovaj upit
SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 668936,36

first time execution: 175sec!!!
Showing rows 0 - 29 ( 36 total, Query took 175.9067 sec)

second time is ok
Showing rows 0 - 29 ( 36 total, Query took 0.0003 sec)

svi ovi upiti se PRVI put uzasno sporo izvrsavaju, dok kad se refreshuju ili opet izvrsi ISTI upit onda sve bude normalno oko 1sec

SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 587456,36
SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 452369,36
SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 698745,36


isto se desava sa fulltext pretragom, prvi put katastrofa, dok sledeci put bolje

koristi se memcache na serveru, ali dzabe to kad se prvi put ceka ogromno vreme
.
svaka pomoc dobrodosla!


znam za resenje WHERE record_num >698745 AND record_num <698835

ali to ne mogu da odradim jer ima "rupa" medju record_num


 
Odgovor na temu

tarla

Član broj: 15527
Poruke: 1648



+42 Profil

icon Re: uzasno spor obican select upit , tabela 1GB sa 700000 redova07.11.2011. u 22:32 - pre 150 meseci
Drugi put je ok zato što je upit keširan.

Uradi EXPLAIN upita da vidimo šta se dešava. Daj strukturu tabele da vidimo kakva polja sortiraš


 
Odgovor na temu

VladaSu

Član broj: 31634
Poruke: 1099
*.dynamic.isp.telekom.rs.



+218 Profil

icon Re: uzasno spor obican select upit , tabela 1GB sa 700000 redova07.11.2011. u 22:54 - pre 150 meseci
Indeksiraj record_num.

[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
95.180.41.*

Sajt: mysql.rs


+2377 Profil

icon Re: uzasno spor obican select upit , tabela 1GB sa 700000 redova07.11.2011. u 23:16 - pre 150 meseci
upit

SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 668936,36

je pogresan (da ne upotrebim neku drugu rec) i MORA da traje.
Duzina trajanja tog upita iskljucivo zavisi od brzine diska. Mozes da racunas na disk cache i innodb_buffer_pool ako je tabela mozda innodb ali opet ne mozes da ocekujes da ce se cela tabela uvek nalaziti u keshu a tebi ovde treba cela tabela

1. nemas nikakav uslov za upit, znaci SELECT mora da procita SVIH 700000 slogova
2. onda svih tih 700000 mora da sortira da bi ti dao 36 komada posle 668936tog

dakle, ne mozes da ubrzas taj upit, mozes da redizajniras bazu tako da ti takav upit nikad ne treba. Ako je record_num slucajno unique index po njemu bi ubrzao sortiranje mada 175sec za citanje 700k slogova prilicno brzo tako da pretpostavljam da je record_num vec indexiran.

sad ti mozes da mi kazes, ali to je tabela sa pesmama i covek lista pesme i ima 36 po strani i kada dodje na 18581tu stranu onda imamo ovaj upit. Ako ti korisniku treba da dozvolis da ide next next stranu po stranu do 18581. strane onda ga pusti da saceka 3 minuta da mu se strana izgenerise, al bas bi voleo da vidim toga ko je otisao na 18581 stranu rucno !!! doticnu moze da nabode samo neki crawler i to je to ... dakle app terba da ima "max" broj strana koje ce da prikaze (20 je vise nego dovoljno, 100 je izivljavanje), ako neko zeli rezultat sa 21 strane, neka suzi kriterijum pretrage.

To sto se upiti izvrsavaju brzo par sekundi posto je upit izvrsen je zato sto
1. query cache iskesira ceo rezultat upita (taj rezultat izleti prvi put kada se nesto u tabeli promeni)
2. disk cache / ibd buffer pool iskesiraju taj deo diska (to opet izleti odatle kada mu nesto drugo zauzme mesto)

ako hoces da proveris sta ti ubrzava taj upit izvrsi ga dva tri puta sa:

SELECT SQL_NO_CACHE record_num,title FROM content ORDER BY record_num DESC LIMIT 668936,36;

to ce ga izvrsiti bez query cache-a ali ce disk i ibd cache biti upotrebljeni pa vidi koliko ce drugi i treci put raditi brze

E sada, sa ovolikom tabelom i slicnim upitima treba da obratis paznju na partitioning ali
1. zelis da predjes na 5.5 zato sto to tamo radi bolje
2. svejedno moras da radis redizajn db modela i aplikacije posto ovaj prosto ne valja

Kreni od proste cinjenice, koliko ti vremena treba da iskopiras fajl od 1G sa diska u /dev/null ..

 
Odgovor na temu

Shinhan
PHP programmer
Subotica

Član broj: 12327
Poruke: 372
*.static.isp.telekom.rs.

Jabber: shinhan@elitesecurity.org
ICQ: 400847988


+4 Profil

icon Re: uzasno spor obican select upit , tabela 1GB sa 700000 redova08.11.2011. u 08:02 - pre 150 meseci
Da se nadovežem na Bogdana, nema poente prikazivati sve rezultate.

Čak i google, iako nekad kaže da postoje milioni rezultata, on ograničava pretragu na prvih 1000 stranica. Tako da, ako google to radi pa skoro niko ne zna za to, znači da ni ostalim smrtnicima nisu potrebni milioni rezultata.
"Common sense is not so common." - Voltaire
 
Odgovor na temu

farmaceut
Apoteka
Banja Luka

Član broj: 182739
Poruke: 55
188.124.197.*



+30 Profil

icon Re: uzasno spor obican select upit , tabela 1GB sa 700000 redova22.11.2011. u 14:36 - pre 150 meseci
Citat:
znam za resenje WHERE record_num >698745 AND record_num <698835
ali to ne mogu da odradim jer ima "rupa" medju record_num


A sto za prvu pomoc ne dodas jedan auto_inc integer,ako mozes stavis ga kao pk ili bar indexiras , i odradis istu selekciju po njemu? Preskocit ces "rupe" i trebalo bi da odradi dosta brzo.
 
Odgovor na temu

[es] :: MySQL :: uzasno spor obican select upit , tabela 1GB sa 700000 redova

[ Pregleda: 2400 | Odgovora: 5 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.