První částí odpovědi je dobrá zpráva... že mysqlcheck -o není pravděpodobnější, že poškodí vaši databázi, než spuštění OPTIMIZE TABLE na každém stole, protože to je vše. Je to pohodlný nástroj, který se přihlásí na server, načte seznam tabulek, iteruje je a odešle OPTIMIZE TABLE dotaz na server pro jednu tabulku najednou, dokud to není hotovo.
Teď pár špatných zpráv. Pokud máte ve svých tabulkových prostorech latentní poškození, OPTIMIZE TABLE může narazit, takže byste si měli být jisti, že jste na tuto možnost připraveni pomocí záloh a plánu obnovy. Pravděpodobnost je poměrně malá, ale je jeden možný výsledek.
Horší zpráva:téměř jistě štěkají na špatný strom.
Společné spouštění Apache a MySQL na stejném počítači se značným provozem – nebo výraznými změnami provozu – je v rozporu s osvědčenými postupy a je receptem na problémy, protože obě služby mají tendenci zvyšovat spotřebu paměti při zatížení, a pokud je databáze zálohou ukládat data webových stránek, pak má tendenci ke zvýšenému zatížení obou služeb současně.
Viz moje odpověď na InnoDB Crash Post Mortem na Stack Exchange správců databází a Proč Apache běží divoce a zabíjí MySQL o chybě serveru pro důkladné pokrytí tohoto poměrně běžného problému, kde je obětí MySQL, více než cokoli jiného.
Všimněte si, že nezáleží na tom, zda používáte InnoDB nebo ne. Záznamy obnovy databáze v protokolu chyb MySQL budou trochu jiné, ale mrtvá prozradí je tato:nepředchází vůbec nic podezřelého, protokol chyb MySQL říká:
mysqld_safe Number of processes running now: 0
Zprávy následující po tomto jsou často mylně interpretovány jako "zhroucení" MySQL, ale to se neděje... Bylo to zabito. MySQL může dokonce odmítnout restart, dokud se Apache neuklidní nebo nerestartuje nebo dokud se server nerestartuje. Opět v protokolu chyb můžete nebo nemusíte dodatečně vidět něco takového:
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
Kontrola /var/log/syslog nebo /var/log/messages (v závislosti na tom, které distro spustíte) vám ukáže skutečný problém.
$ sudo egrep 'kernel|oom' /var/log/syslog
...nebo zprávy... by měly odhalit řadu záznamů začínajících nějak takto:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache je tak hladový po paměti, že systému hrozí celková nestabilita, takže se „něco“ obětuje. To „něco“ bude pravděpodobně démon serveru MySQL, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL se obvykle pokusí restartovat samo o sobě a jak víte, může se to občas také stát... ale pokud paměťové nároky Apache rychle neklesnou, MySQL nebude moci vyžadovat dostatek paměti od systému a vzdát se.
Optimalizace stolů má své platné aplikace... ale v tomto případě, pokud jsem správně identifikoval váš problém, by to bylo velmi srovnatelné s přeskupením lehátek na potápějící se lodi Titanic. Může vám to ušetřit místo na disku, ale také vás to bude stát nějaké volné místo na disku při běhu, protože některé úložné systémy vytvoří zcela novou kopii tabulky, pak kopii přejmenují a starou tabulku odstraní. V každém případě je nepravděpodobné, že by to mělo nějaký významný dopad na spotřebu paměti.