Cum ziceam, principii stiu si eu, chestia cu alter mi-a rezolvat in trecut problema dupa vreo 3 zile de smuls parul din cap (momentan tocmai am pus mentenanta si astept sa iasa userii care mai sunt logati sa pot da cu db-ul de pamant). Voiam sa inteleg mai exact specifics ca sa stiu ce sa urmaresc.
On Tue, Apr 23, 2024 at 6:08 PM Alex 'CAVE' Cernat via RLUG < [email protected]> wrote: > e poveste luuuunga cu indecsii, nu numai pe maria, ci si pe oricare alta > baza de date, poate pe astea mai enterprise trebuie sa mesteci mai > putin, insa din cand in cand tot nu scapi de "mentenanta" > > presupunand ca indecsii sunt la fel si pe master si pe slave (desi din > ce-mi aduc aminte in replicari binare nici nu cred ca se poate altfel), > inseamna ca statisticile sunt "outdated" pe unul din ele, si de aia ai > query plan-uri diferite (la fel, presupun ca versiunile de maria sunt > aceleasi pe master si slave) > > in principiu un analyze pe tabela/tabele ar trebui sa ajunga; optimize > nu e suportat pe innodb, pur si simplu va recrea tabela (actually, cam > la fel face si la un alter table add/drop index); ca sa intreb asa: ai > multe update/delete pe respectivele tabele incat sa se fragmenteze? > (desi indecsii sunt alta mancare de peste) > > ca idee, in orice query pentru fiecare instanta de tabela (ca poate e de > 2 ori sau poate ceva subquery etc) este folosit un singur index, pe care > il considera maria mai "atractiv"; de aceea cand vad jde indecsi pe o > singura coloana ma uit urat, pentru ca cel mai probabil mai mult de > jumatate din ei sunt total inutili; intotdeauna trebuie preferati > indecsi compoziti, prin care sa prinzi cam tot ce e where si join, dar > aici depinde exact ce query-uri ai si cat de multa memorie iti permiti > (asta si vis-a-vis de recomandarile ca toata baza sa fie in innodb_pool, > ceea ce - desi corect per se - mi se pare total si absolut overkill); > inca ceva, IIRC: daca printr-un index nu pare ca se filtreaza macar 20% > din tabela/rezultate, atunci o sa cam faca full table scan > > poate daca descrii un pic tipurile de indecsi si query (fara a da tot > query-ul ca deh, confidential stuff) ne mai vine vreo idee > > Alex > > On 23-Apr-24 14:19, Petru Rațiu via RLUG wrote: > > Ma poate ajuta cineva sa inteleg la ce se uita mariadb (cu engine-ul > > innodb) cand decide query plan la un query? Problema mea e ca am niste > > query-uri care se fac mult mai greu pe master fata de slave care au date > > identice, diferenta fiind ca slave-ul are date refacute dintr-un dump > > recent (si resincronizat). Query planul arata diferit intre cele doua > > servere si in trecut cand am mai avut problema asta s-a rezolvat dupa ce > am > > "optimizat" tabelele implicate (cu un alter table force). > > > > Stiu eu asa din legendele Olimpului ca planul se face pe baza unor > > statistici pe indecsi mentinute in background, dar nu m-am lamurit din > > documentatie unde sunt tinute, cum sa le urmaresc si daca le pot da un > sut > > mai simplu fara sa fac alter care dureaza 10 minute. Am gasit niste > povesti > > despre mysql.innodb_index_stats dar la o prima vedere si aia e replicata > si > > am oricum o jena sa modific chestii pe acolo fara sa inteleg. Also, nu > m-am > > prins daca am vreun mecanism de-a-l convinge pe mariadb sa zica cum a > ajuns > > la concluziile din explain. > > > > Ce carti de mysql am prin casa trec mai rapid peste subiectul asta si am > o > > banuiala ca implementarea de innodb din mariadb s-ar putea sa faca > > lucrurile putin altfel (as putea sa ma dau prin codul sursa dar nu prea > > sunt familiarizat cu internals, prefer sa intreb inainte). > > > > Mersi, > > > > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
