dva klijenta, dakle dve konekcije, query-i se izvrsavaju paralelno. Ako nema zakljucavanja slogova izvrsavaju se paralelno ... dakle ako svaki za sebe traju 2min .. najverovatnije ce ta dva "isovremeno" da traju 2min

a što ako su obadva ista ili se slogovi djelomično preklapaju?

ako se poklapaju podaci a select-ovi su u pitanju u zavisnosti od storage engine-a .. samo citanje iz tabele ce biti kesirano (innodb_buffer_pool_size za innodb na primer) ... tako da ce podaci biti citani sa diska samo jednom umesto dvaput ..

ako nisu selectovi, vec promene, transakcije ce lokovati jedna drugu ako rade nad istim podacima pa ce ta dva upita cekati jedan drugi, isto i sa kombinacijom select/update, zavisno od isolation levela moze da uspori (lokovanje) ili ne ..

isto tako, moras da vodis racuna o dead-lock-u ... ako imas dve konkurentne transakcije koje menjaju isti blok podataka

vezano za selektove, mysql ima implementaciju query cache-a .. koja moze da ubrza znacajno rad ako imas mnogo "identicnih" upita ... dakle query cache kesira tako sto pravi mapu UPIT=REZULTAT ... te samo identicni upiti imaju benefit ... do 5.1 prepared statements nisu mogle da koriste query cache, sada mogu