[ujdzie]

Mam tabelę prostych wpisów, ma ~1GB. Porobione indeksy, na localhoście wszystko śmiga jak głupie (poniżej 0.1s), a na dzielonym VPS-ie klęka zupełnie i pierwsze zapytanie robi w 15-20s (powtórne już szybko)... po czym po chwili i tak chyba gubi ten cache i zamula od nowa.

Warunki w zapytaniu to published = 1 AND deleted = 0 AND category IN ('costam co się zmienia') + order by id desc, mają założone indeksy osobno na każdą kolumnę, jak i na ww. warunki razem

OCB? Za mało ramu? Jakieś opcje można pozmieniać? Jakieś pomysły? Mam wrażenie, że sortowanie po ID (zwykły int) tu sporo miesza

Teraz to wisi u Hertznera, ale na WebH i CyberFolks było to samo.

#bazydanych #mysql #mariadb

[sobol86]

@ujdzie tam można wyświetlić plan zapytania?

[ujdzie]

@sobol86: profiling? No to potwierdziło moje podejrzenie co do sortowania

[sobol86]

@ujdzie no ja bym tez obstawil. Moze warto założyć index klastrowany w oparciu o te kolumne?

[januzi]

@ujdzie: Zrób jeszcze explain do zapytania.

[ujdzie]

@sobol86: @januzi: widzę, że explain są różne (sorry, że takie maleństwo)

Zasadnicze pytanie jest takie - jak poprawnie zorganizować indeksy skoro zawsze odpytuję z warunkami
- published i deleted (zawsze)
- opcjonalnie z kategorią
- sortowanie z reguły id DESC

[januzi]

@ujdzie: Zobacz na localu published + deleted + category + id

Na localu masz tyle samo danych co na serwerze?
I jak wyglądają liczby przy poszczególnych kolumnach? Ile jest published z 1, deleted z 0 i category z poszczególnymi wartościami?

[ujdzie]

@januzi: wrzucam identyczną kopię bazki na remote, więc za chwilę sprawdzę, ale same wartości wyglądają tak:

[januzi]

@ujdzie: No, to jak widać najlepszy indeks chyba będzie category + id.

[ujdzie]

@januzi: na produkcji to będzie inaczej wyglądało po jakimś czasie, na razie jest świeży import, gdzie są tylko opublikowane i nie ma usuniętych

[januzi]

@ujdzie: Jeśli usuniętych/wyłączonych będzie dużo mniej niż opublikowanych, to: where id not in ( )

[ujdzie]

@januzi: a teraz to mnie zgubiłeś zupełnie. Nie znam idów usuniętych/nieopublikowanych żeby je listować w IN

[januzi]

@ujdzie: Mysql zna. W nawiasie może być select, albo lista wcześniej pobranych. I jeśli coś będzie wyłączane/kasowane tak na amen, to lepiej przenieść to do osobnej tabeli.