2011/6/22 Mircea MITU <[email protected]>:
> Salut
>
> empiric am observat ca daca anumite site-uri php/mysql merg greu, uneori
> performanta lor se schimba radical in bine dupa cateva operatii in
> mysql, precum: check/repair/analyze/optimize.
>

Ai uitat si aspiratul ventilatoarelor, stropitul cu tamaie si
sfestania la biserica (n-au ce sa strice, nu?)

Asa cum puteai sa afli daca pierdeai vreo juma de ora prin
documentatie, comenzile astea fac chestii foarte diferite:
- check table verifica (read-only) daca tabela sau indecsii sunt corupti;
- repair table incearca sa repare problemele de mai sus (in masura in
care engine-ul suporta si cu rezultate care uneori depind si de tipul
si numarul lumanarilor aprinse);
- optimize face treburi diferite in functie de engine, dar in
principiu defragmenteaza datele, ceea ce ajuta si la spatiul pe disc,
si la i/o (ca in aceleasi blocuri din disk cache ai mai multe date
relevante) - nu stiu daca innodb recent suporta si defragmentarea
indecsilor, pana pe la 5.0 nu facea asta;
- analyze e ceva mai interesant, intrucat reface statisticile pt.
query optimizer (dar iarasi e diferenta de la cer la pamant in functie
de engine, de exemplu pe innodb e relativ cheap, dar mai euristic, pe
myisam e cu full index scan si table lock) - un indiciu bun ca ar
merita facuta chestia asta este momentul in care apar in slow query
log query-uri la care planul dat de explain e la padure.

> Deoarece experienta mea cu mysql nu este suficienta pentru acest
> scenariu, intreb catre cei mai experimentati:
>     1. care e secventa corecta / optima a acestor taskuri? exista un
>        best practice in domeniu?

Depinde enorm de mult de ce fel de date ai, ce fel de schema, cat de
repede se schimba, natura query-urilor, samd. In masura in care
performanta e relativ importanta business-wise, sugerez sa apelezi la
un DBA care sa se uite la grafice (faci grafice, nu?), sa se uite la
slow_query.log (ai asa ceva?), sa analizeze schema (o (de)normalizare
la vremea ei face cat zece ... nu gasesc rima) inainte sa faca un cron
cu sql_turbo_button.sh.

>     2. exista deja vreo metoda de automatizare a acestor task-uri pe
>        toate tabele/bazele de date?
>

Cu siguranta se poate face un cron pe genunchi, dar faptul ca
engine-ul n-o face automat ar trebui sa ridice mari semne de intrebare
privind motivele pt. care ai vrea asa ceva.


-- 
Petre.
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug

Raspunde prin e-mail lui