[es] - null, join i table lock

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

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

Sajt: www.tojesoft.co.rs

+5 Profil

null, join i table lock

^{17.12.2010. u 22:34 - pre 162 meseci}

Kako se MySQL snalazi sa:

1. null vrednostima u kolonama. da li se nedostatak default vrednosti -> dozvoljavanje null-ova odrazava na performanse? jednom davno sam procitao negde da baze ne vole null vrednosti ali nikad se nisam upustao u to zasto je to tako. jednostavno, prihvatio sam i uvek gledam da mi kolona bude NOT NULL, makar sa default value. moze par reci na tu temu, čisto informativno?

2. join, pa još jedan, pa još 3, itd. stalno viđam upite gde je join-ovano 4+ tabele u upitu, od kojih neke i nisu baš male. kako se MySQL (query optimizer?) snalazi u takvoj situaciji?

3. ako nemam baš previše distinct vrednosti po indexu, da li dolazi do lockovanja tabele, kao kod MSSQL-a? ako da, da li postoji neka vrednost, kriterijum, po kome mogu da očekujem kad će mysql zaključati celu tabelu? pretpostavimo da se radi upit po koloni koja je indexirana al, kažem, ima malo distinct vrednosti.

Acta, non verba!

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: null, join i table lock

^{17.12.2010. u 22:51 - pre 162 meseci}

Citat:

bjevta: Kako se MySQL snalazi sa:

1. null vrednostima u kolonama. da li se nedostatak default vrednosti -> dozvoljavanje null-ova odrazava na performanse? jednom davno sam procitao negde da baze ne vole null vrednosti ali nikad se nisam upustao u to zasto je to tako. jednostavno, prihvatio sam i uvek gledam da mi kolona bude NOT NULL, makar sa default value. moze par reci na tu temu, čisto informativno?

savrseno. baze nemaju nikakav problem sa null vrednostima - korisnici koji ne znaju sql imaju problem sa null vrednostima .. null je nista, nije vece ili manje od nesto ..

Citat:

2. join, pa još jedan, pa još 3, itd. stalno viđam upite gde je join-ovano 4+ tabele u upitu, od kojih neke i nisu baš male. kako se MySQL (query optimizer?) snalazi u takvoj situaciji?

zavisi od storage engine-a i od dizajna baza... ako je moguce koristiti indexe mysql ce ih koristiti, ako ne - bice sporo ... generalno mysql je daleko od "najbolje" baze kada se radi o velikim joinovima (sa mnogo tabela), ali isto tako daleko da je medju najgorima :) ... ima par sitnica koje ne smem da spominjem (oracle policy vezano za sta ce biti sutra) ali radimo na necemo sto ce mysql gurnuti u sam vrh sto se tih velikih joinova tice ...

Citat:

3. ako nemam baš previše distinct vrednosti po indexu, da li dolazi do lockovanja tabele, kao kod MSSQL-a? ako da, da li postoji neka vrednost, kriterijum, po kome mogu da očekujem kad će mysql zaključati celu tabelu? pretpostavimo da se radi upit po koloni koja je indexirana al, kažem, ima malo distinct vrednosti.

zavisi .. ako koristis myisam svaki lock je po tabeli :D ... e sad sto se tice lokova po kljucu to se menjalo vremenom, iskreno nemam pojma kako ovaj najnoviji plugin radi ali mislim da on "nikad" nece zalokovati celu tabelu, sve i da imas samo jedan drugaciji slog taj jedan ce ostati nelokovan.. to nije uvek "najbolje" resenje (ono sto radi mssql moze da bude bolje nekad - ali to je nekad radio i mysql ali je vraceno - valjda zato sto su nam se klijenti zalili a nikome se nije svidelo to zakljucavanje cele tabele ... ) - no, kao sto rekoh, nisam bas ispratio ceo ovaj plagin od pocetka do kraja mnogo smo radili na ndbcluster engine-u (7.0 i 7.1 imaju ultra mnogo novih stvari) ...

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

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

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

Sajt: www.tojesoft.co.rs

+5 Profil

Re: null, join i table lock

^{18.12.2010. u 06:51 - pre 162 meseci}

e, da, setih se još nečeg. Da li treba koristiti UUID (GUID) ili Long ili Integer za primarni ključ spada u "database religion", što neko reče. Mene interesuje nešto drugo. Ako bih za PK koristio CHAR(16) ili CHAR(8) ili neki binary(16), da li bi to uticalo na performanse kod CRUD ili JOIN operacija? Dakle, PK bi bio nad jednom kolonom, fiksne širine i bio bi duži od BIGINT-a. Pretpostavimo da nema replikacije.

Acta, non verba!

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: null, join i table lock

^{18.12.2010. u 14:29 - pre 162 meseci}

koristi sta god oces... obrati paznjuu da je UUID/GUID VELIK tako da ce ti primarni kljuc biti ogroman te ce ti trebati mnogo vise rama da ga kesiras, takodje obrati paznju da mysql nije optimizovan za rad sa UUID-om tako da je rad sa njim mnogo sporiji (skoro kao da ti je pk string) ... tako da koristenje int (bigint ili koliki vec oces) je brze, ali nije "mandatory"... ako hoces brzinu, fora je da ti pk bude sto manji, dakle ako neces prebaciti vise slogova nego sto INT pokriva, nemoj da koristis bigint i slicno ... sto je manji index, vise njega mozes da kesiras u istoj kolicini rama

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu