Citat:
masinac_1:
Nego, to sto kazes desi se da je i 2 dana kasnije uneto to nesto sto se spremalo. Meni je bitno kada je poceo unos, tj. kada je id rezervisan a ne kada je unos okoncan.
ti NE ZNAS kada je ID REZERVISAN posto se ID ne rezervise samo u slucaju transakcije vec se rezervise kada to i kako to storage engine u kombinaciji sa hendlerom odradjuje. Na primer kada je ndbcluster u pitanju, auto_inc vrednost se rezervise kada se prvi put upisuje u tabelu koja ima auto_inc. Na primer sql nod rezervise 1024 id-a. To ne znaci da mu treba 1024 za tu transakciju .. samo znaci da je uzeo toliko, dakle tvoj slog sa ID-om iz tih 1024, rezervisan je juce, ali tvoja aplikacija je pozelela da upise slog danas tako da - ta dva podatka nisu ni u kakvoj relaciji ..
Cak i kada "ZNAS" kako se id rezervise (pogledas source pa vidis) - to nije "kvalitetna informacija" posto taj order / taj nacin alokacije id-a nije nicim zagarantovan i vec u sledecoj verziji / podverziji / bildu moze da se promeni te na to ne smes da se "oslonis"... sto je storage engine kao sam rdbms "pametniji" to manje stvari ovog tipa mozes da koristis posto optimizacije uveliko koriste ono sto "nije garantovano sql standardom" da bi ubrzale razne stvari...
primer .. (ne vezan direkno ali)
Code:
select * from (select a,b,c from t1 order by a) x;
po kom ce redosledu ovaj select vratiti rezultat? pravilan odgovor je "nemam pojma". Kako SQL standard kaze da subquery ako nema limit order kojim vraca podatke je nebitan, prvo sto ce optimizer da uradi ovde je da izignorise order by A kompletno. Drugo - kako "glavni" (spoljni) select nema order by - opet, potpuno je nepoznato kojim redom ce da vrati rezultat sve i da je onaj subquery i bio sortiran... Zvuci nelogicno ali zamisli da imas proces koji cita fajl sa diska, mozes da citas fajl jednim tredom i citas ga od pocetka do kraja i to je neki "logican i najbrzi" nacin, ali zamisli da to radis sa 4 treda koji citaju fajl i pakuju podatke za slanje .. tada svaki tred cita 25% fajla sto znaci da ce podaci da se pakuju kao 1, 5, 9, 2, 6, 19, 3, 7, 11, 4, 8, 12, ... e sad zamisli da imas 20 tredova koji sluze za to i deljeni su medju upitima, pa ako imas 2 upita svakom zapadne po 10 tredova, ako imas 1 dobije svih 20 a ako imas 20 upita svaki dobije po samo jedan ... dakle bilo kakava racunica "kojim ce redom" nesto doci pada u vodu ...
Citat:
AKo mozes da mi pojasnis kada tacno se rezervise/odredjuje id za nesto slicno sledecem:
Code:
INSERT INTO tabela (podatak1, podatak2, podatak3, podatak4) VALUE ('$podatak1', '$podatak2', '$podatak3', '$podatak4')
Recimo da je proces poceo (kliknuto na "do" ili "insert") u 22:49:50, da je za obradu ovih podataka potrebno 20s, a samo upisivanje traje recimo 2sec. U koliko sati je rezervisan id i sta bi pisalo u polju vreme_unosa cija vrednost se odredjuje sa NOW() ?
zavisi od storage engine-a do storage engine-a, od verzije samog storage engine-a i od verzije mysql-a do verzije mysql-a i od dodatnih parametara ... i to samo ako gledamo mysql, ako gledamo dalje od mysql-a ...
recimo ako gledamo myisam - auto_increment je uzet onog trenutka kada se upisuje vrednost. MyISAM za razliku od ostalih tu nema neku pametnu logiku posto mu ne treba, kako radi sa table level lockingom uvek samo jedan thread pise po tabeli tako da on uzme auto_inc vrednost iz meta vrednosti tabele, upise je u slog, poveca meta vrednost za jedan i otkljuca tabelu ..
za innodb zavisno od verzije do verzije i od parametara u my.cnf ako transakcija ima 100 slogova rezervisace se 100 auto_inc vrednosti na pocetku transakcije (ako je mysql svestan da mu treba 100) ili ce se rezervisati jedan po jedan, u nekom slucaju ce interlocking transakcije da imaju interlocking id-eve a u nekom sekvencijalno grupe id-eva, nekad ce biti "po redu" a nekad nece. Dakle bez problema moze da ti se desi da unutar jedne transakcije id-evi ne idu po redu. Ali generalno kada je innodb u pitanju alokacija auto_inc-a ide na pocetku i tokom transakcije i po zavrsetku transakcije nema viska id-eva koji nisu iskoristeni (ovo ce mozda vrlo brzo da se promeni)
za ndbcluster na primer, sql nod rezervise od data noda broj auto increment vrednosti prvi put kada mu "zafali" auto_inc vrednost. Kolicina se setuje u my.cnf. Kada se transakcija zavrsi, neiskoristene vrednosti se cuvaju "za kasnije" tj za "kad zatrebaju" ili "dok se ne resetuje sql nod" - i nikada se ne vracaju nazad. Tako da sql nod moze da rezervise auto_inc vrednosti danas a da ih koristi narednih mesec dana (ako je na primer rezervisao 1000 komada a upisujes 10 slogova dnevno)
Pritom - ovo nista nije GARANTOVANO .. bez ikakve najave bilo sta od ovoga moze da se promeni, bas zato - auto increment vrednost ne sme da se koristi za bilo kakav "redosled" posto ona samim SQL standardom nikakav redosled ne garantuje.
da se vratim na pocetak - ako hoces da nesto sortiras po vremenu upisa, jedini nacin da to uradis pravilno je da upises vreme kada si ga upisao i sortiras po tom vremenu .. sve ostalo sto "skoro radi" nije garantovano da ce raditi u prvoj sledecoj verziji...