Pierwsza część odpowiedzi to dobra wiadomość... że mysqlcheck -o nie jest bardziej prawdopodobne, aby zaszkodzić Twojej bazie danych niż uruchomienie OPTIMIZE TABLE na każdym stole, ponieważ to wszystko, co robi. Jest to wygodne narzędzie, które loguje się do serwera, pobiera listę tabel i przechodzi przez nie, wysyłając OPTIMIZE TABLE wysyła zapytanie do serwera o jedną tabelę na raz, dopóki nie zostanie zakończone.
A teraz kilka złych wieści. Jeśli masz ukryte uszkodzenie w swoich obszarach tabel, OPTIMIZE TABLE może na niego natknąć się, więc powinieneś być pewien, że jesteś na to przygotowany, z kopiami zapasowymi i planem odzyskiwania. Szanse na to są dość niewielkie, ale jest jeden możliwy wynik.
Gorsze wieści:prawie na pewno szczekają niewłaściwe drzewo.
Uruchamianie Apache i MySQL razem na tej samej maszynie o dużym natężeniu ruchu — lub znacznej zmienności ruchu — jest sprzeczne z najlepszymi praktykami i jest receptą na problemy, ponieważ obie usługi mają tendencję do zwiększania zużycia pamięci pod obciążeniem i jeśli baza danych stanowi bazę przechowywać dane z witryn internetowych, wtedy zwiększone obciążenie występuje zwykle w obu usługach w tym samym czasie.
Zobacz moją odpowiedź na InnoDB Crash Post mortem na giełdzie administratorów baz danych i Dlaczego Apache działa dziko i zabija MySQL w przypadku awarii serwera za dokładne omówienie tego dość powszechnego problemu, którego ofiarą jest MySQL, bardziej niż cokolwiek innego.
Zauważ, że nie ma znaczenia, czy używasz InnoDB, czy nie. Wpisy dotyczące odzyskiwania bazy danych w dzienniku błędów MySQL będą nieco inne, ale martwa wskazówka jest taka:poprzedzona niczym podejrzanym, dziennik błędów MySQL mówi:
mysqld_safe Number of processes running now: 0
Komunikaty następujące po tym są często błędnie interpretowane jako "awaria" MySQL, ale to nie jest to, co się dzieje... Został zabity. MySQL może nawet odmówić ponownego uruchomienia, dopóki Apache się nie uspokoi lub nie zostanie ponownie uruchomiony lub serwer zostanie ponownie uruchomiony. Ponownie, z dziennika błędów możesz, ale nie musisz, dodatkowo zobaczyć coś takiego:
InnoDB: Initializing buffer pool, size = 4.0G
InnoDB: mmap(4395630592 bytes) failed; errno 12
InnoDB: Completed initialization of buffer pool
InnoDB: Fatal error: cannot allocate memory for the buffer pool
[ERROR] Aborting
[Note] /usr/libexec/mysqld: Shutdown complete
mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Sprawdzanie /var/log/syslog lub /var/log/messages (w zależności od uruchomionej dystrybucji) pokaże Ci prawdziwy problem.
$ sudo egrep 'kernel|oom' /var/log/syslog
...lub wiadomości... powinny zawierać kilka wpisów zaczynających się mniej więcej tak:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache jest tak głodny pamięci, że system jest zagrożony ogólną niestabilnością, więc „coś” zostaje poświęcone. Tym "coś" prawdopodobnie będzie demon MySQL Server, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL zwykle będzie próbował samoczynnie uruchomić się ponownie i, jak wiadomo, czasami może się to zdarzyć... ale o ile żądania pamięci Apache'a nie znikną szybko, MySQL nie będzie mógł zażądać wystarczającej ilości pamięci z systemu i będzie poddaj się.
Optymalizacja stołów ma swoje ważne zastosowania... ale w tym przypadku, jeśli prawidłowo zidentyfikowałem Twój problem, byłoby to bardzo podobne do zmiany ustawienia leżaków na tonącym statku Titanic. Może to zaoszczędzić trochę miejsca na dysku, ale będzie też kosztować trochę wolnego miejsca na dysku podczas pracy, ponieważ niektóre silniki pamięci masowej tworzą całkowicie nową kopię tabeli, a następnie zmieniają nazwę kopii i usuwają starą tabelę. W każdym razie jest mało prawdopodobne, aby miało to znaczący wpływ na zużycie pamięci.
