Cum ziceam, stiu deja teoriile astea. Wtf-urile mele au inceput cand mi-am dat seama ca query-ul care dura 3 minute pe master termina in cateva secunde pe slave, avand aceleasi date; vad ca la explain cele doua servere au idei diferite despre in ce ordine sa inceapa joinurile (ala rapid pleaca cu un dataset relativ mare la inceput dar dupa aia sunt mai simple restul de chestii). N-am reusit sa ma prind cum pot zice db-ului sa-mi zica mai mult despre la ce s-a uitat cand a facut planul (evident amicii cu postgres au zis ca la ei e simplu) si nu inteleg exact pe unde pe disc sunt tinute datele astea sa ma pot uita mai exact la ele nu sa aflu ca toata ziua de marti a mers infect cu acelasi gen de trafic ca luni.
Cat despre scheme cu force index... Pe langa ca nu sunt sigur de ce ar fi mai util alt index in cazul ala, e foarte multa ungabunga de framework si de ORM pe drum unde nu-s convins cum as putea insera hinturi dinalea... -- P. On Tue, Apr 23, 2024 at 6:20 PM Alex 'CAVE' Cernat via RLUG < rlug@lists.lug.ro> wrote: > 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 > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
