[ Shinhan @ 24.03.2008. 15:13 ] @
Znam, znam, naravno da su velike tabele sporije nego manje tabele.

Prvo opis. Ima jedna log tabela, sa 5.7mil rekorda. PHPMyAdmin kaže da je Row length 184 a Row Size 238 B (pretpostavljam da je to prosek).
Podaci zauzimaju 1G a indeksi 300MB
Problem je što se čak i običan "SELECT * FROM velikatabela WHERE foreignKey = 12345" sporo izvršava, treba mu 111 sekundi :(

Koje je najbolje rešenje?
* Da bacim još 2GB RAM na mašinu u nadi da će cela tabela stati u memoriju?
* Da isečem ovu veliku tabelu na više delova, tako da svaki deo može stati u memoriju i onda skupljam podatke pomoću union...
* Neka tajna podešavanja servera ili operativnog sistema?

Pošto je ovo ipak log tabela, ne treba mi brzina pristupa manja od 1s, ali nadam se da je moguće smanjiti ovo na nekih 10-20 sekundi? Analiza logova je vrlo zamorna kada se čeka 2 minuta na odaziv >.<

Za sada planiram drugu opciju. Koji je najbolji način za to sečenje? Napraviti tabelu velikatabela_arhiva1 i onda pustiti insert select da baci stare podatke u arhivu (iz komandne linije)? Da li ima neki brži način? Nadam se da insert select radi samo row-lock, pošto bi table lock nekoliko sati bio... nepoželjan.
[ Miroslav Ćurčić @ 24.03.2008. 17:02 ] @
Neću da pitam ima li index ta kolona "foreignkey" jer se za log tabele to izbegava, sve u cilju da bi upis bio što brži, a to je najčešća operacija, mnogo češća od čitanja.

Dakle, preporučio bih da uvedeš drugu tabelu "old_logs" u koju ćeš (recimo cron-om) povremeno prebacivati najstarije podatke iz dosadašnje tabele, recimo starije od mesec dana.
Dalje na stranici s koje gledaš te logove dodaš jedan checkbox s opisom "traži i u arhiviranim logovima" tako da ti ta spora pretraga bude samo kad baš to i zatrebaš.
[ misk0 @ 24.03.2008. 20:08 ] @
Potpisujem prethodno predlozeno rjesenje - arhiva + aktuelni podaci
[ Shinhan @ 25.03.2008. 07:05 ] @
A da indeksiram arhivnu tabelu?

Na log tabeli onda da ostavim samo primary key?
[ misk0 @ 25.03.2008. 08:15 ] @
Obe tabele trebaju imati Primary Key i index. Mozda ne razumijem sta hoces da kazes?
[ Shinhan @ 25.03.2008. 09:02 ] @
Ono 2 minuta selekt, nisam stavio index po tom polju >.<
Pošto je bilo 5 indexa mislio sam da je i ovo polje bilo indexirano, ali kad sam jutros došao na posao vidim da nije. Oops.
Inače, indexi su jedan fulltext, dva su nad integer poljima, jedan datumski i jedan nad enum poljem.

Citat:
misk0: Obe tabele trebaju imati Primary Key i index. Mozda ne razumijem sta hoces da kazes?


Citat:
mVeliki: Neću da pitam ima li index ta kolona "foreignkey" jer se za log tabele to izbegava, sve u cilju da bi upis bio što brži, a to je najčešća operacija, mnogo češća od čitanja.
...

mVeliki kaže skini indexe, ti kažeš stavi. Nisam baš siguran koliko mi indexi usporavaju insertovanje. Takođe, pošto ovaj log prati mejlovanje, mislim da je slanje meilova dosta sporije nego insertovanje u vrlo indexiranu tabelu.
[ misk0 @ 25.03.2008. 11:17 ] @
Primary key je indexiran vec, stavi indexe samo na kolone po kojima vrsis pretrazivanje. Osim toga, foreignkey se odnosi na drugu tabelu koju je spominjao mVeliki, pod uslovom da je imas.
[ Miroslav Ćurčić @ 25.03.2008. 21:09 ] @
Mislio sam da je ta tabela logova nešto u šta se piše pri svakom pristupu stranici,
recimo na svakih par sekundi ili još gore više puta u jednoj sekundi.
Tada bi imalo smisla poizbacivati indexe iz aktuelne tabele da bi se maximalno ubrzalo,
ali ovo što sad pominješ i nije toliko učestalo.

Komotno ih možeš obe indexirati kako želiš.