si inca ceva, desi aici deja tine de programare:
intotdeauna poti folosi in query use index sau chiar force index, daca
maria e prea tembela (si din pacate am prins-o in offside, ce-i drept,
si query-urile erau de-a dreptul cretine, dar deh, nu puteau fi
modificate substantial din pacate)
iar daca result set-ul e relativ mic, poti sa te joci cu deferred joins
(in special cand gasesti imbecilisme de genul select * - ca atat s-a
putut), procedura prin care intr-o prima faza selectezi in general
id-uri si apoi pe baza lor poti sa selectezi si row-uri intregi, daca ai
programatori lenesi; in felul asta nu mai scrie maria de nebuna pe disc
tabele temporare imense (asa cum face daca vede ca are texte si bloburi
prin tabela)
https://aaronfrancis.com/2022/efficient-pagination-using-deferred-joins
idem sunt bune si covering indexes, aka toate coloanele din result-ul
respectiv sunt acoperite de index/indecsi, si atunci (presupunand ca
indexul e in memorie) nu se mai duce pe disc sa citeasca tone de date
iar legat de ce-ai cerut punctual (aka statistici de indecsi) sunt si eu
curios, pana acum n-am gasit nimic de genul
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
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
