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
