Nu sunt un MySQL guru (pentru simplul motiv ca MySQL nu este o baza de date tranzactionala...versiunea 5 e in probation time") dar problema poate fi abordata mai general (eu am ceva mai multa experienta pe Firebird,Oracle si PostgreSQL):
On 2/14/06, Serghei Amelian <[EMAIL PROTECTED]> wrote: > Am o baza de date foarte mare in mysql (cam 650.000 de inregistrari, cu foarte > multe campuri). Am mai adaugat cateva campuri si m-am apucat umplu campurile > alea cu "UPDATE table SET blabla". 650 k inregistrari nu sunt multe, dar operatiunile de I/O depind foarte mult de lungimea inregistrarii. In Firebird alocarea de spatiu se face la nivel de pagina, iar lungimea unei pagini poate varia de la 1k la 16k. Pentru multe campuri e de preferat sa ai o lungime de pagina de 8k sau chiar 16k. Vezi daca in MySQL ai un asemenea parametru. > Acum am o chestie enervanta, umplerea campurilor noi se face extrem de lent, e > ca si cum nu ar fi spatiu pe disc alocat pentru ele si se aloca in momentul > ala (activatatea hdd-ului este intensa), si creste enorm memoria alocata > pentru "Disk Cache" (stiu ca in mod normal e multa memorie alocata pentru > asta, dar acum pur si simplu imi arunca in swap celelalte aplicatii). Vezi paragraful de mai sus. In Firebird poti sa mai specifici si numarul de pagini al disk cache-ului, iar teoretic ar exista o plaja in zona 8k-16 pagini (*deci inmultit cu dimensiunea unei pagini) pentru care accesul la disk cache e optimizat. Valori prea mari inseamna rezultate prea slabe plus ca maninca prea mult din "SO disk cache" si nu e eficient. Dar repet, chestiile astea sunt valabile pentru Firebird dar exista parametri similari pentru orie RDBMS care se respecta. Si deja patrundem in teritoriul voodoo aka RDBMs tunning. > > Exista vreo posibilitate sa-i spun mysql-ului sa prealoce mai mult spatiu pe > disk pentru noile date? Daca fac inca o data update pentru datele deja > introduse merge extrem de repede. Daca nu gasesti un parametru de genul asta o pseudo-solutie ar fi sa sa fortezi alocarea spatiului pe disc prin valori DEFAULT acolo unde este posibil. La numerice te mai scoti, mai nasol e la VARCHAR si CHAR. In situatia ta cred ca mai bine folosesti CHAR in loc de VARCHAR ..nu cred ca ai probleme cu spatiul pe disc. > > Thanks > -- > Serghei. Bafta la tunning. _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
