apropos de ordine diferita in join, am patit niste chestii de astea,
unde desi bagasem la greu indecsi tocmai pentru a optimiza query-urile,
ma trezeam ca incepe cu a doua / treia tabela ca i se parea lui ca ar fi
mai avantajos, si binenteles ca se alegea praful de query time, ca desi
la prima vedere avea dreptate, in final o lua rau pe ulei cu tabele
temporare, full table scan & shit
atunci un straight_join bine tintit il calma, pentru a forta ordinea de
join; insa cu framework si orm-uri se mai complica treaba, ca nu stiu
cat de mult control low level ai pentru asa ceva; chit ca by default
nu-mi place sa dau cu bocancu in masa cu force index si forced join,
dupa cum ziceam am cam prins-o pe maria de multe ori pe aratura, asa ca ...
de curiozitate uita-te prin 'show index from $tabela', in special pe
cardinalitate; si eventual mai verifica inca o data ca sunt definiti la
fel (ar fi culmea sa nu fie, dar ... deh, nu se stie niciodata, shit
happens everytime)
si inca un hint: analyze format=json $query, iti da niste info in plus
fata de explain, inclusiv timpi (dar vezi ca ruleaza si query-ul in
spate, ceea ce e bine pentru raport, insa tu stii cat de bine e pentru
server si date)
mysql 8 are suport mult mai misto pentru ce am zis mai sus (output-ul
seamana foarte mult cu ce iese de la postgres), insa la maria mai e de
asteptat se pare (la 10.5 garantat nu e ... sau poate cine stie,
descopar si eu apa calda :-P)
Alex
On 23-Apr-24 18:44, Petru Rațiu wrote:
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
<[email protected]> 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
[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
