wolne JDBC i mysql?

Robię inserty ( co 5secund ) z poziomu java przez jdbc taki insert z shella mysql robi się 0 secund. Robię też czytanie (innym procesem ) na tej samej tabeli zapytanie trwa średnio 30ms (milisecund).

Każde z osobna robi się fajnie i mysqld chodzi fajnie w ogóle nie czuje zmęczenia.
Jak ustawię dwa procesy naraz tzn pisanie i czytanie (każde z osobna bardzo krótkie) to mysqld zużywa
CPU 99% czytnie idzie na 10secund (pisanie nie sprawdzałem)

Zapewne masz tak ustawioną izolację transakcji. Zauważ że jak piszesz to nie możesz czytać (jeśli masz tam two-phase lock).

Dzięki za odpowiedź. domyślne wszystko jest myisam " insert deleyed ... " a select normalny. Zadnych blokad w postaci lock nie robię.

dodam że ta tabela jest bardzo duża tabelą ok 1mln rec ale w zamierzeniu ma tam być i 300mln

myisam blokuje dane na poziomie tabeli więc nie dziw się że tak to działa ;]

Dzięki za odp. czyli co trzeba zrobić żęby to wydajnie chodziło? Zmiana na innodb nie zmieniła nic.

Hmm a jakie zapytania w takim razie puszczasz? I czemu chcesz jednocześnie pisać i czytać? Bo to jest zwykle słaba opcja.

Oba oddzielnie: inesert delayed 0sec i select średnio 30milisec.
Oba razem: to select idzie do kilku secund nawet do 6sec przy 100mln recordów

omg ale jak wygląda ten insert? na jakich tabelach, z jakimi powiazaniami? są tam triggery jakieś?
jak wygląda ten select? ile tabel w nim łączysz? które tabele? ile wierszy wyciągasz tym selectem?

Dzięki za odp. to ma znaczenie jak te zapytania wygladają? Czasy ich trwania są wg mnie istotniejsze.
Sedno to to że w parze select (z insertem który idzie z jdbc) działa długo do 10secund. A sam gdy nie ma pisania to 30milisecund.

1. Nie wiem czemu nie umiesz napisać sekund i milisekund, to są normalne słowa po polsku
2. Czy ty jesteś poważny? Przecież to jest najistotniejsza sprawa CO te zapytania robią, a nie ile trwają. Przecież select całej zawartości tabeli może trwać milisekundy, tak samo update całej tabeli może trwać milisekundy, ale robienie obu jednocześnie może trwać bardzo długo, bo zapytania będą się nawzajem blokować na wierszach i wielokrotnie czytać z dysku/pisać na dysk.
   Jak selec leci sam, to może sobie dać locka na całą tabelę i wczytać wszystko na raz. A jak ktoś mu blokuje wiersze, to musi czytać sobie po wierszu. W efekcie zamiast 1 odczytu z dysku, będziesz miał ich tysiące (tyle ile stron na dysku zajmuje ta tabela). Analogicznie z updatami.

Dzięki. Ciekawe to co piszesz. Jakoś mało wydajnie ten mysql jest zrobiony.
Select składa się z dwóch podzapytań jeżdzących po tej samej tabeli grupujacych po polu na tabeli są założone są 2 indexy i primary key po id

Zwykle to nie kwestia "mało wydajnie" zrobionego systemu bazodanowego, tylko mało wydajnie napisanych zapytań, ktorych optymalizator kosztowy nie daje rady doprowadzić do sensownej postaci...

Ok dzięki za odpowiedz. Zwykły insert na trzech kluczach 0sekund i select z 3 podzapytaniami 30milisekund tabela ok 1mln rekordów.
A oba razem to i 10secund trwają. przy czym inserty idą cyklicznie co jakiś czas co 5sekund.