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

Optimizacija Query-ja i tabele

[es] :: MySQL :: Optimizacija Query-ja i tabele

[ Pregleda: 2417 | Odgovora: 17 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

doktor83
Subotica

Član broj: 293583
Poruke: 50

Sajt: www.oxo.rs


+1 Profil

icon Optimizacija Query-ja i tabele13.12.2011. u 19:53 - pre 150 meseci
Hocu da optimizujem sledeci query :

Code:

SELECT
o.*, types.type as type, categories.category AS category, c2.category as parentName, from_sites.from_site AS from_site
FROM oglasi AS o
LEFT JOIN categories ON o.category_id = categories.category_id
LEFT JOIN from_sites ON o.from_site_id = from_sites.from_site_id
LEFT JOIN types on o.type_id = types.type_id
LEFT OUTER JOIN categories c2 on categories.parent = c2.category_id
WHERE from_sites.from_site_id = 4 
ORDER BY izdvojen,title ASC
LIMIT 0, 10;


Nisam nikada ranije radio ovako nesto , pa bi mi dobrodosle smernice. Ako ovaj gornji query moze nekako da se optimizuje to bi mi bio prvi korak.
Evo recimo jednog pitanja , posto mi uopste nije jasno zasto se ovo desava:

Imam primary key na o.oglas_id i ni jedan drugi index u ovoj tabeli.
Imam jos index na from_sites.from_site_id koji je takodje primary key.
Ako izvrsim query pod ovim uslovima dobijem:

# Query_time: 1.616000 Lock_time: 0.000000 Rows_sent: 10 Rows_examined: 375644

Odnosno explain mi kaze za tabelu o (oglasi) ovo :
1 SIMPLE o ALL NULL NULL NULL NULL 375604 Using where

Koliko sam saznao iz nekog tutorijala na netu ovo ne valja ovako,pa sam probao da stavim index na o.from_site_id i misleci da cu dobiti neko ubrzanje,
iznenadio sam se:

# Query_time: 3.350000 Lock_time: 0.001000 Rows_sent: 10 Rows_examined: 218087

Kao prvo koliko vidim query je prosao kroz manje redova nego malopre,a ipak mu je trebalo duplo vise vremena!
A explain se sad ne zali,kaze :

1 SIMPLE o ref from_site_id from_site_id 1 const 217931 Using where

Znaci nije mi jasno zasto upotrebom indexa ne da nisam dobio ubrzanje,vec mi se duplo sporije izvrsio upit.

Zapravo ovaj gornji query se sastavlja dinamicki , ali sam za primer uzeo ovo (from_site_id=4) zato sto tom doticnom id-ju odgovara tih 217 hiljada redova.

Jos jedno pitanje,najvise mi se radi upit po polju o.title koje mi je sad varchar , i u php-u trazim sa LIKE "%izraz%" .
Da li bih dobio neko ubrzanje ako bih na o.title stavio full text index ?

Svaka pomoc je dobrodosla!
EDIT: Koristim Mysql 5.1.54 i odradio sam test sa FULL TEXT-om i radi dosta brze. Naravno prethodno pitanje jos uvek stoji,odnosno kako da optimizujem gornji query ?

[Ovu poruku je menjao doktor83 dana 13.12.2011. u 22:12 GMT+1]
----------------------------------------------------------
www.oxo.rs
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
95.180.61.*

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija Query-ja i tabele14.12.2011. u 00:06 - pre 150 meseci
moras da postavis CEO izlaz od "EXPLAIN EXTENDED pa tvoj upit" da bi znali sta se desava


 
Odgovor na temu

doktor83
Subotica

Član broj: 293583
Poruke: 50

Sajt: www.oxo.rs


+1 Profil

icon Re: Optimizacija Query-ja i tabele14.12.2011. u 07:09 - pre 150 meseci
Evo za prvi primer (kada imam index samo na o.oglas_id)

Code:

+----+-------------+------------+--------+---------------+---------+---------+----------------------------+--------+----------+----------------+
| id | select_type | table      | type   | possible_keys | key     | key_len | ref                        | rows   | filtered | Extra          |
+----+-------------+------------+--------+---------------+---------+---------+----------------------------+--------+----------+----------------+
|  1 | SIMPLE      | from_sites | const  | PRIMARY       | PRIMARY | 4       | const                      |      1 |   100.00 | Using filesort |
|  1 | SIMPLE      | o          | ALL    | NULL          | NULL    | NULL    | NULL                       | 375604 |   100.00 | Using where    |
|  1 | SIMPLE      | types      | eq_ref | PRIMARY       | PRIMARY | 4       | oxo_temp.o.type_id         |      1 |   100.00 |                |
|  1 | SIMPLE      | categories | eq_ref | PRIMARY       | PRIMARY | 4       | oxo_temp.o.category_id     |      1 |   100.00 |                |
|  1 | SIMPLE      | c2         | eq_ref | PRIMARY       | PRIMARY | 4       | oxo_temp.categories.parent |      1 |   100.00 |                |
+----+-------------+------------+--------+---------------+---------+---------+----------------------------+--------+----------+----------------+


a evo ga i za drugi (index na o.from_site_id)

Code:

+----+-------------+------------+--------+---------------+--------------+---------+----------------------------+--------+----------+----------------+
| id | select_type | table      | type   | possible_keys | key          | key_len | ref                        | rows   | filtered | Extra          |
+----+-------------+------------+--------+---------------+--------------+---------+----------------------------+--------+----------+----------------+
|  1 | SIMPLE      | from_sites | const  | PRIMARY       | PRIMARY      | 4       | const                      |      1 |   100.00 | Using filesort |
|  1 | SIMPLE      | o          | ref    | from_site_id  | from_site_id | 1       | const                      | 217931 |   100.00 | Using where    |
|  1 | SIMPLE      | types      | eq_ref | PRIMARY       | PRIMARY      | 4       | oxo_temp.o.type_id         |      1 |   100.00 |                |
|  1 | SIMPLE      | categories | eq_ref | PRIMARY       | PRIMARY      | 4       | oxo_temp.o.category_id     |      1 |   100.00 |                |
|  1 | SIMPLE      | c2         | eq_ref | PRIMARY       | PRIMARY      | 4       | oxo_temp.categories.parent |      1 |   100.00 |                |
+----+-------------+------------+--------+---------------+--------------+---------+----------------------------+--------+----------+----------------+



----------------------------------------------------------
www.oxo.rs
 
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: Optimizacija Query-ja i tabele14.12.2011. u 07:12 - pre 150 meseci
Koristiš "LEFT JOIN" i "LEFT OUTER JOIN". Nešto mi se čini kao da misliš da ima razlike između te dve. LEFT JOIN i LEFT OUTER JOIN se potpuno isto ponašaju.

MySQL docs on JOIN

Sa druge strane, u WHERE koristiš polje iz treće tabele, pa mi se čini kao da si hteo umesto "LEFT JOIN" da staviš "INNER JOIN"? U najmanju ruku, nema poente stavljati ne-INNER join-ovane tabele u WHERE uslove.
"Common sense is not so common." - Voltaire
 
Odgovor na temu

VladaSu

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



+218 Profil

icon Re: Optimizacija Query-ja i tabele14.12.2011. u 11:56 - pre 150 meseci
Code (sql):

SELECT
o.*, types.TYPE AS TYPE, categories.category AS category, c2.category AS parentName, from_sites.from_site AS from_site
FROM oglasi AS o
LEFT JOIN categories ON o.category_id = categories.category_id
LEFT JOIN from_sites ON o.from_site_id = from_sites.from_site_id
LEFT JOIN types ON o.type_id = types.type_id
LEFT OUTER JOIN categories c2 ON categories.parent = c2.category_id
WHERE from_sites.from_site_id = 4
ORDER BY izdvojen,title ASC
LIMIT 0, 10;
 

Ako nemas puno rekorda u categories, from_sites i types onda ovo mozes na sledeci nacin da resis.
Razdovji u vise sql-ova:
Code (sql):

SELECT o.*
FROM oglasi AS o
WHERE o.from_site_id = 4
ORDER BY izdvojen,title ASC
LIMIT 0, 10;
 

Gde ti je from_site_id indexiran a verovatno moze i kolona izdvojen da bude inexirana.

Trebace ti jos 3 sql ( mozda i nece u zavisnosti sta prikazujes)
Jedan je gde vadis sve iz tabele from_sites gde je id = 4
Drugi je da vadis kategorije a treci type.
Ovo sve mozes da kesiras jer se verovatno ne menja cesto tako da neces imati ova 3 upita.
Ako kesiras i from_sites ti nije velika onda ti ne treba uslove where id = 4.
Onda u programskom kodu u kojem radis od ovih max 10 rekorda sto si dobio u prvom sql-u dodas kolone from_site, category i type.



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

doktor83
Subotica

Član broj: 293583
Poruke: 50

Sajt: www.oxo.rs


+1 Profil

icon Re: Optimizacija Query-ja i tabele14.12.2011. u 14:41 - pre 150 meseci
Mislim da ne mogu da razmisljam o kesiranju posto se podaci u celoj tabeli oglasi menjaju nedeljno (flush pa se ponovo puni),
a i ovaj gornji query mi se dinamicki kreira.
Moze da izgleda i ovako npr. :

Code:

SELECT o.*, categories.category AS category, c2.category as parentName, from_sites.from_site AS from_site FROM oglasi AS o 
LEFT JOIN categories ON o.category_id = categories.category_id 
LEFT JOIN from_sites ON o.from_site_id = from_sites.from_site_id 
LEFT JOIN categories c2 on categories.parent = c2.category_id 
WHERE (MATCH(title) AGAINST ('kosulja') OR MATCH(title) AGAINST ('kosulje')) AND 
(o.category_id = 16 OR o.category_id = 157 OR o.category_id = 158 OR o.category_id = 159 OR o.category_id = 160 OR o.category_id = 161 
OR o.category_id = 162 OR o.category_id = 217 OR o.category_id = 218 OR o.category_id = 239) 
AND o.from_site_id = 4 
AND price > 1 AND price < 8000 
ORDER BY CASE WHEN LOCATE("kosulja",title) > 0 THEN 0 ELSE 1 END,izdvojen,title ASC LIMIT 0, 10


Da prica bude jos zanimljivija potreban mi je i ukupan broj vracenih redova zbog paginacije.
Prvobitno sam koristio SQL_CALC_FOUND_ROWS , pa sam sa FOUND_ROWS() saznao koliko je vraceno redova.
Sada odradim 2 posebna querija , ovaj gornji i jos jednom ovaj gornji ali sa COUNT, i posle testiranja sam dosao
na to da ustedim negde oko sekundu do sekunde ipo ako radim bez CALC_FOUND_ROWS.

Citao sam negde da se MYSQL bolje snalazi sa vise uzastopnih manjih upita nego sa jednim vecim.
Mada ja ne smatram da ovaj moj upit spada u vece,al ajde,da li bih dobio na brzini ako bih sve posebno
izvrsavao,kao sto je to Vlada predlozio ?


----------------------------------------------------------
www.oxo.rs
 
Odgovor na temu

VladaSu

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



+218 Profil

icon Re: Optimizacija Query-ja i tabele14.12.2011. u 15:05 - pre 150 meseci
I ovaj sql moze da ti se svede na onaj primer sto sam ti poslao jer su ti svi uslovi iz oglasi tabele.
Cak i count sql moze da ti ide sa tim kracim sql-om.
Kada sam pricao o kesiranju mislio sam na category, from_sites i type tabele koje ti se veoma retko menjaju.

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

doktor83
Subotica

Član broj: 293583
Poruke: 50

Sajt: www.oxo.rs


+1 Profil

icon Re: Optimizacija Query-ja i tabele14.12.2011. u 16:10 - pre 150 meseci
Probacu ovako kao sto si predlozio Vlado.
A sto se kesiranja tice,jel mozes malo da mi pojasnis na kakvo si kesiranje mislio?
Jel moze primer? :)


----------------------------------------------------------
www.oxo.rs
 
Odgovor na temu

VladaSu

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



+218 Profil

icon Re: Optimizacija Query-ja i tabele14.12.2011. u 17:11 - pre 150 meseci
Vidim da koristis php pa mozes koristiti APC, memcache ili da zapisujes u txt fajl. Zavisi sta imas na serveru.
[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]
 
Odgovor na temu

doktor83
Subotica

Član broj: 293583
Poruke: 50

Sajt: www.oxo.rs


+1 Profil

icon Re: Optimizacija Query-ja i tabele14.12.2011. u 23:32 - pre 150 meseci
Nemam nista od navedenog,znaci u text fajl.
Nesto sam razmisljao i na temu da kesiram dnevno najcesce query-je (posto ljudi dosta klikcu na najtrazenije izraze)
i onda se isti upit poziva cesto. Samo ne znam da li bih sa ovime dobio nesto na brzini posto mysql kesira upite,
samo je pitanje (i ono sto ja ne znam) koliko ih dugo drzi u cache-u. Znaci ako neko posalje neki upit recimo ujutro u 9 , pa
se taj upit ponovo posalje u 9.12 , pa u 9.40 itd. da li se on svaki put iznova kreira i pretrazuje ili mu se vraca kesirani rezultat?
----------------------------------------------------------
www.oxo.rs
 
Odgovor na temu

bjevta
Bratislav Jevtic
http://www.tojesoft.co.rs
Beograd

Član broj: 5216
Poruke: 367
*.static.sbb.rs.

Sajt: www.tojesoft.co.rs


+5 Profil

icon Re: Optimizacija Query-ja i tabele15.12.2011. u 11:36 - pre 150 meseci
svi ti oglasi imaju ne 'zivotni vek'.
da li je 300 000 oglasa aktivno u svakom trenutku. koliko ih je ukupno?
moze biti da bi mogao pomoci datum kreiranja oglasa ili status (OPENED/CLOSED) ili slicno uz, recimo, particionisanje.
da li su interesantni podaci stariji od, na primer, 3 meseca? itd...
Acta, non verba!
 
Odgovor na temu

bjevta
Bratislav Jevtic
http://www.tojesoft.co.rs
Beograd

Član broj: 5216
Poruke: 367
*.static.sbb.rs.

Sajt: www.tojesoft.co.rs


+5 Profil

icon Re: Optimizacija Query-ja i tabele15.12.2011. u 12:22 - pre 150 meseci
ah, da, jos nesto:

SELECT o.*, types.type AS type, categories.category AS category, c2.category AS parentName, from_sites.from_site AS from_site
FROM oglasi AS o
LEFT JOIN categories ON o.category_id = categories.category_id
LEFT JOIN from_sites ON o.from_site_id = from_sites.from_site_id
LEFT JOIN types ON o.type_id = types.type_id
LEFT OUTER JOIN categories c2 ON categories.parent = c2.category_id
WHERE from_sites.from_site_id = 4
ORDER BY izdvojen,title ASC
LIMIT 0, 10;

ne valja. prvo, uopste ti ne treba join, jer u ovoj tabeli OGLASI vec imas ID-jeve kategorija i sajtova. napisi nesto ovako:

SELECT o.*
FROM oglasi AS o
WHERE o.from_site_id = 4
ORDER BY izdvojen, title ASC
LIMIT 0, 10;

dalje, ne treba sve kolone da se dobavljaju odmah u prvom cugu. prvo dobavi ID-jeve, lako ces posle ceo 'oglas'. moze biti da je ovako brze.

SELECT o.oglas_id
FROM oglasi AS o
WHERE o.from_site_id = 4
ORDER BY izdvojen, title ASC
LIMIT 0, 10;

e, da, proveri sledece parametre MySQL-a: tmp_table_size, max_heap_table_size, max_tmp_tables i innodb_buffer_pool_size i javi njihove vrednosti

Acta, non verba!
 
Odgovor na temu

doktor83
Subotica

Član broj: 293583
Poruke: 50

Sajt: www.oxo.rs


+1 Profil

icon Re: Optimizacija Query-ja i tabele15.12.2011. u 13:09 - pre 150 meseci
Bratislave,
Zivotni vek ovih oglasa je da kazemo UVEK AKTIVNI,zato sto sve oglase (oko 400.000) nedeljno
brisem i ponovo ih unosim. Ne radi se o obicnom sajtu za male oglase vec o agregatoru malih oglasa/proizvoda.
TAko da nesto tipa starije od 3 meseca ni ne postoji kod mene,pa nazalost uvek moram kroz sve redove da prolazim
kada neko pretrazuje recimo po kljucnoj reci.

Sto se tice pravljenja vise manjih upita, to cu probati cim budem imao vremena,pa se javljam.
MOgu a i ne moram da imam puno kriterijuma u queryju (posto se WHERE kreira dinamicki), ali sve te
podatke vadim samo iz jedne tabele (oglasi),pa se zbog toga i nadam nekom ubrzanju od vise manjih upita.

A evo i sledecih parametara :

tmp_table_size : 16777216
max_heap_table_size : 16777216
max_tmp_tables : 32
innodb_buffer_pool_size : 134217728

Mada ovaj poslednji ne verujem da me preterano interesuje posto koristim MyIsam tabele.
----------------------------------------------------------
www.oxo.rs
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
95.180.61.*

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija Query-ja i tabele17.12.2011. u 04:29 - pre 150 meseci
Citat:
doktor83: ,zato sto sve oglase (oko 400.000) nedeljno brisem i ponovo ih unosim.


sto znaci da imas nedelju dana iste oglase tj nedelju dana ti je to "read only" tabela sto znaci da mozes da kesiras ohoho .. nardkas qcache na max, index cache ... bacis indexe na drugi lun u odnosu na datu (create table lalalalalal.... engine=myisam data directory=/dsada/das/das/da index directory=/dsa/das/da ) takoda dobijes malo veci io na masini

Citat:
doktor83:pa nazalost uvek moram kroz sve redove da prolazim kada neko pretrazuje recimo po kljucnoj reci.


spomenuto je vec vise puta oko full tekst pretrage - to bez nekog lucene-a ili sphinx-a ne mozes da resis da valja, bez njih to nikada nece raditi kako treba. mysql-ov full text key je "ok" ali su ova specijalizovana resenja MNOGO bolja, posebno sto imas update nedeljno

Citat:
doktor83:Mada ovaj poslednji ne verujem da me preterano interesuje posto koristim MyIsam tabele.


ako uopste ne koristis innodb onda ga UGASI da ne trosi resurse
 
Odgovor na temu

doktor83
Subotica

Član broj: 293583
Poruke: 50

Sajt: www.oxo.rs


+1 Profil

icon Re: Optimizacija Query-ja i tabele17.12.2011. u 09:48 - pre 150 meseci
Bogdane , hvala na savetima , al imam samo jedan problem : shared hosting :)
Znaci nemam pristup podesavanjima mysql-a ... :)
----------------------------------------------------------
www.oxo.rs
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
95.180.61.*

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija Query-ja i tabele17.12.2011. u 09:59 - pre 150 meseci
znas kako to ide sa parama i muzikom ... dedicated hosting imas za 50E mesecno, cak i jeftinije ... i sigurno ce biti bolji od tog shared .. tebi na podatke koji se ne menjaju nedelju dana qcache i disk cache resavaju gomiletinu problema, realno to mora da leti cak i kad su upiti lose napisani i baza ocajno modelirana, ali ti na shared hostingu nemas od toga vajde posto oni moraju ili da ugase qcache ili da ga znatno zabodu da bi odgovarao "svima" a disk cache ne stize da iskesira nista tvoje posto ima ko zna koliko usera ...

dalje, bilo kakvo testiranje vremena trajanja upita na shared hostingu je beskorisno posto ne znas sta server drugo radi dok ti testiras

Nemoj pogresno da me shvatis ali, ako imas 1M slogova i radis nedeljni update, kapiram da je rec o nekom poslu, ako taj posao ne moze da isplati 50eur mesecno za jedan server - jj.ee.bb.oo. poso
 
Odgovor na temu

doktor83
Subotica

Član broj: 293583
Poruke: 50

Sajt: www.oxo.rs


+1 Profil

icon Re: Optimizacija Query-ja i tabele17.12.2011. u 13:22 - pre 150 meseci
hahaha,pa u pravu si potpuno,ali eto za sada ima novaca samo za shared.. ako se malo razvije biznis naravno da prelazim na dedicated :)
Hteo sam na neki nacin da skratim vreme potrebno za izvrsavanje upita na trenutnom hostingu,ma kakav on bio.. I u tome sam i uspeo,
eto srezao sam ovaj gornji upit sa 7-8 sec na neki 4-5 , pa sam mislio ako moze jos nesto za 'dz' :)
----------------------------------------------------------
www.oxo.rs
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
95.180.61.*

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija Query-ja i tabele17.12.2011. u 13:34 - pre 150 meseci
odoh ja u off ali mozda pomogne

sta je fora, sa shared hostingom ne mozes da znas kako ti se tacno app ponasa i to pravi ogroman problem. Dodatno, MySQL je pateticno lose uradjen za shared hosting :( zato je i nastao drizzle da omoguci laksi/bolji shared hosting rdbms-a. Ono sto je zeznuto za posao je sto te pretrazivaci (koji ti u startu donose preko 90% traffic-a) penalizuju drasticno ako ti je sajt spor (pa se pojavljujes na 20toj strani umesto na prvih par) tako da ni ne mozes da razvijes biznis sa sporim sajtom ... jer ne dobijas traffic, da ne spominjem da neces imati povratnih korisnika posto ce da pobegnu od sporog sajta ... zato je bitno od starta ici na varijantu da to za sto manje para radi sto bolje, ja licno mislim da je 50E za server (u poredjenju sa ~10e koliko verovatno sada placas) premala cifra da rizikujes da ti ceo projekat propadne ..
 
Odgovor na temu

[es] :: MySQL :: Optimizacija Query-ja i tabele

[ Pregleda: 2417 | Odgovora: 17 ] > FB > Twit

Postavi temu Odgovori

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