1. jedan upit na mysql serveru se izvrsava uvek u jednom tredu.
2. jedan tred moze da trci samo na jednom procesoru u jedno vreme.
3. myisam ima samo table locking


1+2 = ako imas upit koji smara cpu taj upit ce zabosti jedan cpu (jezgro) a ostala jezgra ce piti kafu i cekati da ih neki drugi tred pozove na igranku
1+2+3 = ako upit koji dugo traje menja neke podatke nad tabelom, taj upit ce tu tabelu zakljucati (celu) tako da ce svi ostali upiti koji imaju sta pitati tu istu tabelu sedeti zajedno sa onim slobodnom jezgrima i grickati semenke dok ovaj dugotrajni smarac ne zavrsi svoje i ne odkljuca tabelu


resenje = videti "sta" drzi "koga" zakljucanim, sledeci put kad se tako zabode a ti pukni jedan "show full processlist" pa vidi koji procesi "piju kafu" a koji "vodi koju tabelu u bioskop", onda razmisli da li ti se isplati da tu tabelu bacis u innodb (koji ima row level locking te dozvoljava da razlicite delove tabele istovremeno menja vise tredova) ili da prepises tog svalera da radi malo drugacije / brze

Da priupitam i ja nesto na brzaka... :) onako usput...

Lokuje li select upit tabelu... ?

naravno ... e sad, kakav lock, to zavisi od storage engine-a, vrste select-a i slicno ..

za myisam, select uzima "read lock" (odnosno, ne uzima lock nego samo sprecava kreiranje exclusive lock-a) sto znaci da drugi selectovi mogu da rade paralelno (select for update na myisam-u nema mnogo smisla). Ono sto je nezgodno kod myisam-a je ako imas

SELECT (A)
UPDATE
SELECT (B)

sada dok traje ovaj select(A) bi bez problema mogao da trci i SELECT(B) ali posto update ima veci prioritet on ceka na exclusive lock nad tabelom dok se select(a) ne zavrsi, onda ce on da odradi sta ima (update) i onda ce tek select (b) da radi. Teoretslo ke select(b) mogao ranije da se izvrsi - al ... e sad, to resavas tako sto koristis update niskog prioriteta (imas opciju u configu) te ce onda select(b) da se izvrsi odma (nece cekati update) - problem ovde je sto ako imas puno select-a, update ce "mnogo dugo" da ceka na red...

vezano za lokovanje procitaj malo: http://dev.mysql.com/doc/refman/5.5/en/locking-issues.html

Mmmm, mislim da je jasno sada i koliko vidim morace to da se prebaci na innodb.
Ovaj smaracki upit je SELECT, a upiti koji stalno pice i po nekoliko u sekundi, i koji bivaju odsjevani su UPDATE-i i INSERT-i.

Zahvaljujem na odgovoru... pozdrav

da innodb je tu mnogo snalazljiviji ... doduse, ono o cemu mozes da razmislis je da optimizujes taj smaracki select :) ..

Ne znam sta bih mogao da optimizujem u upitu koji mi se cini prilicno prost.



a u tabeli t1 se nalazi vise od 3 miliona rekorda.

AUCH!!

ovaj upit ti SVAKI PUT radi FULL TABLE SCAN :( ... sto zato sto je mysql glup sto iz drugih razloga .. posto je `m` rezultat funkcije, sve i ako imas index po c1 mysql ne ume da ga koristi tako da ide bukvalno red po red kroz svih 3 miliona vadi monthname() i racuna ...

posto nema nikakav where, tebi u svakom slucaju treba full table scan tako da cak i ako bi dodao kolonu c3 u kojoj bi cuvao monthname ne bi imao nikakvo ubrzanje posto bi opet isao kroz celu tabelu, ono sto do duse mozes da uradis je da napravis tabelu `sum_po_mesecima` koja bi imala "monthname" i "zbir" i koju bi odrzavao trigerom (nad t1 napravis triger nad insert/update i delete koji u zavisnosti od operacije radi ++ ili -- nad onom tabelom sa 12 redova ... na taj nacin nemas vise taj ocajni select koji ti zabada celu bazu ... a inserti i update-i nad t1 su neznatno usporeni