Cum serverul de baze de date MySQL nu a fost conceput pornind de la ideea restrictionarii utilizatorilor veti observa ca intretinerea unui server shared devine un lucru foarte frustrant. Din cauza unor query-uri prost optimizate sau a unor conexiuni proaste serverul MySQL poate ajute sa consume foarte multe resurse incetinind astfel randamentul general al serverului.
In fisierul de configurare nu putem pune foarte multe restrictii iar restrictiile care ni se permit de multe ori nu sunt foarte utile. Unul din lipsurile mari este restrictionarea timpului maxim de executie al unui query. Din punct de vedere al configurarii serverului MySQL nu putem face nimic, dar se poate crea un mic hack cu ajutorul serviciului cron si anume un script care verifica din minut in minut query-urile active iar asupra query-urilor cu probleme se pot lua masuri – le putem opri, le putem loga etc. Un astfel de script ar fi urmatorul:
#!/usr/bin/perl -w # # Numele scriptului: clean_mysql.pl # Versiunea scriptului: 1.0 # Data: 2008 Iulie 01 # Autor: LAMP, webmaster@lamp.ro # Descriere: Cum MySQL nu suporta restrictii pe utilizator, implementez aici timpul # maxim de executie a unu query printr-un cron care ruleaza din minut in minut # si face o verificare a query-urilor active. Scriptul trebuie adaugat in # /etc/crontab de forma: # * * * * * root /scripts/clean_mysql.pl >/dev/null 2>&1 # unde se inlocuieste /scripts/clean_mysql.pl cu calea catre fisierul # script. # use DBI; use define MAXTIME => 30; my $dbh = DBI->connect(’dbi:mysql:mysql’,'root’,'ParolaDeRoot’) or die(”$DBI::errstr”); my $query = “SHOW FULL PROCESSLIST;”; my $result= $dbh->prepare($query) or die(”$DBI::errstr”); $result->execute() or die(”$DBI::errstr”); while( my @row = $result->fetchrow() ){ $dbh->do(”KILL $row[0];”) if( $row[5] >= MAXTIME ); } $result->finish(); $dbh->disconnect();
Nu va recomand sa il folositi in productie decat daca sunteti sigur ce faceti, sau daca il folositi in productie sa aveti grija sa fie totusi niste valori rezonabile. Query-urile prea mari vor fi oprite brusc, asta putand duce la pierderea de date.
Daca se intampla sa dea eroare verificati sa existe modulele DBI si define instalate.
Popularity: 5% [?]



Salut Sergiu!
Am o problema cand dau urmatoarea comanda in mysql
UPDATE tsvcom SET ora=’13:00′,data_m=’18.05.2010′,nota=’Amanta’,data=’18.05.2010′ WHERE id=LAST_INSERT_ID();
iata ce imi afiseaza
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0
mysql>
Nu pot intelege, din ce cauza nu merge,nu face modificarile, cate o data merge, apoi iar nu vrea… din experienta ta ai putea sa imi spui la ce sa atrag atantie?
eu vreau sa modific ultima inserare, imi trebuie asta numai decat, alt paramentru decat id nu am… poate este alta solutie la ce imi trebuie mie, am rascolit tot internetul si asta am gasit-o mai relevanta,insa acum nu merge, poate e problema in mysql, poate fi?
mie nu mi s-a mai intimplat asa ceva…
Multumesc
Viorel
Verifica daca coloana `id` e setata cu AUTO_INCREMENT. Asta e singura posibilitate, presupunand ca nu exista un script care sa goleasca tabela pana rulezi tu queryul.
am verificat, parca e normal
mysql> DESCRIBE tsvcom;
+———+————-+——+—–+———+—————-+
| Field | Type | Null | Key | Default | Extra |
+———+————-+——+—–+———+—————-+
| id | int(11) | NO | PRI | NULL | auto_increment |
| strada | varchar(30) | YES | | NULL | |
| nr | varchar(30) | YES | | NULL | |
si nu imi merge,
am trecut pe mysql pus pe FreeBSD si cat am facut cu manual in mysql a mers normal, dupa ce am conectat programa facuta in java nu mai funcioneaza…
Viorel
Gata, am rezolvat…
mai inainte faceam
Insert…..
Update…..WHERE id=LAST_INSERT_ID();
si nu merge
acum am facut asa
Insert
select MAX(LAST_INSERT_ID(id)) from tsvcom;
update id=’21′;
si merge, ma gandeam sa fac fara select dar nu a vrut…:(
Viorel