![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 21 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (0%) ![]() ![]() |
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. |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 341 Pomógł: 40 Dołączył: 23.06.2009 Ostrzeżenie: (0%) ![]() ![]() |
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. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 7.10.2025 - 09:53 |