| bOkIcA |
15. 08. 2009. 03:28 |
Ne razumem se kompletno ali sumnjam na to da sortiranje te kolicine podataka (20000+) uzima vecinu vremena. To pokazuje i "explain" gde se vidi da se koristi temp tabela pa tkzv filesort jer je verovatno previse materijala za direktnu obradu u memoriji.
Neki predlog moze biti da mozda arhiviras vesti pa da takve upite radis na manjim tj samo aktuelnim podacima ili sl.
|
| srdjevic |
15. 08. 2009. 09:48 |
Probaj ovo:
ALTER TABLE vijesti ADD INDEX `sortindex` (`pozicija`, `datum_objave`);
Onda u upitu u odeljku FROM umesto "vijesti v," stavi "vijesti v FORCE INDEX (sortindex),"
Pravi ti temp tabelu zbog sortiranja, a ne uslova.... ;)
Edit: i daj screenshot explain-a sa ovim cak i ako ne radi brze (osim ako je identican onom iz prve poruke)
|
| mb_sa |
16. 08. 2009. 09:46 |
@degojs
Baza ima preko 20.000 redova, mislim da bi trebalo biti dovljno.
@bOkIcA
Arhiviranje mi trenutno nije opcija. To je planirano, ali nakon odredjenog vremena, gdje bi baza tada imala duplo i vise redova
@srdjevic
http://www.imagesforme.com/show.php/640038_explain2.jpg
Kada odradim FORCE indexa, mysql ga i koristi. Explain daje nesto bolje rezultate, ali pomaka sa brzinom nema. Upit je izgleda najbrzi kada nema ni jednog indexa.
Hvala na dosadasnjoj pomoci. |
| ivanhoe |
16. 08. 2009. 22:28 |
ako nema pomaka sa brzinom, a koristi index za sortiranje (ne pojavljuje ti se filesort), onda je mozda problem u podesavanju servera, da ne moze da stavi ceo index u memoriju jer mu je dodeljena velicina cache-a premala. Jel baza InnoDB ili MyISAM ili nesto trece?
|
| srdjevic |
17. 08. 2009. 18:19 |
Pa da, sad ne koristi temp table, samo filesort... bice da je premali kes... mislim da bi sa vecim kesom ovako radilo bolje od pocetnog.
|
| mb_sa |
30. 08. 2009. 16:47 |
Citat:
Originalno napisao mb_sa
(Napišite 72217)
U MySQL dokumentaciji pise da neće korstiti index za order by ako se mixaju ASC i DESC, mada sam ja stavljao ORDER BY v.pozicija DESC, v.datum_objave DESC, ali opet ista situacija.
Nisam pametan :)
|
Evo da javim sta se je desilo, vjerujm da ce i drugima biti od pomoci.
Povecanje sort i key buffera je pomoglo, ali problem ovog upita je bio "ORDER by pozicija, datum_objave DESC".
Dakle, mysql ne zna da korsiti index ukoliko miksamo ASC i DESC, što je bio kod mene slučaj. Promjena upita na ORDER by pozicija DESC, datum_objave DESC uz kreiran index (pozicija,datum) jer radila dalekoooo brze (reda 0.0010s).
Mejdutim, prolbem je sto vo ne vraca željene rezultate. U tabelu sam dodao pozicija_reverse koja je sadrzava suprotne vrijednosti, tako da sam mogao da sortiram po principu pozicjija DESC, datum_obajve DESC. Naravno kreiran je index za (pozicija_reverse,datum_obajve) i upit se izvrsava za 0.0010.
Povecanje key buffer size sort buffer size je pomoglo da korsiti index (pozicija,datum) tako da je pomoglo i kod ovog upita i generlano kod upita koji su imali samo sortiranje po datumu.
Hvala na pomoci i usescu! |
| Vreme je GMT +2. Trenutno vreme je 01:03. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
