Witam,
w moim serwisie jest wykonywane około 160-180 zapytań na minutę w czasie największego ruchu w ciągu dnia.
Jedno z nich, to zapytanie zawierające słowa kluczowe. Dotychczas zrealizowane było z użyciem LIKE i pole typu VARCHAR(1500), na które założony jest indeks typu FULLTEXT dawało oczekiwane wyniki, tylko wraz z rozrostem serwisu i tym samym bazy zaczęło działać trochę wolno.
Napisałem nową wersję zapytania z wykorzystaniem MATCH AGAINST i tego samego pola oraz indeksu, które działa prawidłowo i daje oczekiwane wyniki, ale powoduje zawieszanie MySQL'a po około 5-15 minutach od momentu wdrożenia skryptu zawierającego nową wersję zapytania, kiedy wracam do poprzedniej z LIKE wszystko jest OK - nie wiem czym może to być spowodowane.

Czy spotkaliście się z czymś podobnym, w czym może być problem?

Z góry dziękuję za wszelką pomoc i wskazówki.

slow loga odpal, sprawdz liste procesowa jakie ci wisza - a wtedy bedziesz wiedzial jakie zapytanie zabija serwer.

MySql slow log odpalony, przeanalizowany - brak zapytania które mogłoby zabić serwer

w chwili gdy serwer jest masakrowany :

SHOW FULL PROCESSLIST; << patrz co i jak długo sie wykonuje,
w konsoli odpal HTOP i obserwuj co zabija procki.


analizując logi - pamiętaj o tym że polecenie zabijające serwer jest dużo wcześniej niz ostatnie zapisy << te ostatnie nie wykonały sie dlatego że brakowało wolnych prockow.
MATCH AGAINST << innodb ? czy myisam ? jeśli myisam - to chyba nie jest to dobry pomysł, pomyśl nad migracją na nowsze serwery.

być może warto pomyśleć o innych rozwiązaniach? np sphinx?
ja, w kluczowych tabelach wykorzystuje silnik memory.
explain - zobacz (i pokaz) co pokazuje na zapytaniach które blokują, może warto pomyśleć nad przeorganizowaniem struktury, może warto pozakładać inne indexy, podzielić na partycje?



jak widzisz - sposobów jest mnóstwo. być możę najlepszym z nich będzie zamówić audyt zewn. jakieś doradztwo.

j.

Dzięki za podpowiedź, będę zatem sprawdzał dalej.
Jeśli FULLTEXT, to według dokumentacji tylko MyIsam i przy tym chciałbym zostać, bo działa wystarczająco szybko - tylko sie wywala

Full-text indexes can be used only with MyISAM tables, and can be created only for CHAR, VARCHAR, or TEXT columns.
http://dev.mysql.com/doc/refman/5.5/en//fulltext-search.html

ha, TYLKO?
poczytaj sobie dokumentacje do 5.6
http://dev.mysql.com/doc/refman/5.6/en/fulltext-search.html

jesli przeszedles na myisam - to kazda operacja ktora cos zmienia (insert/update/delete) na danej tabeli - powoduje jej blokowanie. wtedy wlasnie nawarstwia sie oczekiwanie i wywala serwer

zalecane rozwiazanie - upgrade serwera do wersji 5.6 i bedziesz mial problem z glowy...
rzynajmniej na jakis czas - jesli zwiekszy ci sie ruch wtedy bedziesz moze musial przeprojektowac od nowa ta aplikacje.


edit.
myisam i szybko - to przestarzala opinia, zalecam odswierzenie wiedzy.

http://dimitrik.free.fr/blog/archives/11-0...11-30-2012.html

Co racja, to racja - refresh wiedzy musi być. Dzięki za wskazówki.
BTW: 5.6 jest nadal na GPL? Z tego co znalazłem wnika, że tak, ale chciałbym się upewnić.

hej, niektórzy piszą o ma th against w innodb

Zrób crona co będzie duplikował ci tabelę, jak dobrze ktoś powiedział mylsam jest fajne i szybkie, zajmuje dużo miejsca ale do full text ok.

Tabelę co jest zmień na innodb (przyśpieszysz działanie bo innodb blokuje jeden rekord nie całą tabelę)

Tabelę duplikat zrób w mylsam

Kopiuj cronem np co godzinę jako np create table tabela_nowa as select * from tablica_stara

i masz duplikat tylko do szukania full text bracie bez obciążeń insertów updatów itd.

Z Bogiem!

zamiast crona - mozna uzyc events'a, jedno srodowisko.
tyle ze naprawde warto przesiasc sie na 5.6 i dzialac na innodb, myisam to naprawde przezytek, takze dla math against

j

mysql 5.6 jest na gpl