Het eerste deel van het antwoord is het goede nieuws... dat mysqlcheck -o heeft niet meer kans om uw database te beschadigen dan het uitvoeren van OPTIMIZE TABLE op elke tafel, want dat is alles wat het doet. Het is een gemakshulpprogramma dat inlogt op de server, een lijst met tabellen ophaalt en er doorheen gaat, en een OPTIMIZE TABLE verzendt vraag naar de server voor één tafel tegelijk, totdat het klaar is.
Nu, slecht nieuws. Als je latente corruptie in je tablespaces hebt, OPTIMIZE TABLE kan er tegenaan lopen, dus u moet er zeker van zijn dat u op die mogelijkheid bent voorbereid, met back-ups en een herstelplan. De kans hierop is vrij klein, maar het is een mogelijke uitkomst.
Erger nieuws:blaffen vrijwel zeker aan de verkeerde boom.
Apache en MySQL samen uitvoeren op dezelfde machine met aanzienlijk verkeer - of aanzienlijke verkeersvariatie - is in strijd met de beste werkwijzen en is een recept voor problemen, omdat beide services de neiging hebben om hun geheugengebruik onder belasting te verhogen, en als de database de backing is opslaan voor websitegegevens, dan treedt er meestal een verhoogde belasting op beide services tegelijkertijd op.
Zie mijn antwoord op InnoDB Crash Post Mortem on Database Administrators Stack Exchange en Waarom wordt Apache wild en wordt MySQL vermoord op serverfout voor een grondige dekking van dit vrij veel voorkomende probleem, waar MySQL het slachtoffer is, meer dan wat dan ook.
Merk op dat het niet uitmaakt of u InnoDB gebruikt of niet. De databaseherstelvermeldingen in het MySQL-foutlogboek zullen een beetje anders zijn, maar de dode weggeefactie is dit:voorafgegaan door helemaal niets verdachts, zegt het MySQL-foutlogboek:
mysqld_safe Number of processes running now: 0
De berichten die daarop volgen worden vaak verkeerd geïnterpreteerd als MySQL "crashen", maar dat is niet wat er gebeurt... Het is gedood. MySQL kan zelfs weigeren opnieuw op te starten, totdat Apache kalmeert of opnieuw wordt opgestart, of de server opnieuw wordt opgestart. Nogmaals, in het foutenlogboek kunt u wel of niet iets als dit zien:
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
Controleren van /var/log/syslog of /var/log/messages (afhankelijk van welke distro je draait) zal je het echte probleem laten zien.
$ sudo egrep 'kernel|oom' /var/log/syslog
...of berichten... zouden een aantal items moeten onthullen die ongeveer als volgt beginnen:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache krijgt zo'n geheugenhonger dat het systeem het risico loopt op algehele instabiliteit, dus "iets" wordt opgeofferd. Dat "iets" is waarschijnlijk de MySQL Server-daemon, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL zal meestal zelf proberen opnieuw op te starten, en voor zover u weet, kan dit ook af en toe gebeuren... geef het op.
Het optimaliseren van de tafels heeft zijn geldige toepassingen... maar in dit geval, als ik uw probleem correct heb geïdentificeerd, zou het zeer vergelijkbaar zijn met het herschikken van de ligstoelen op het zinkende schip Titanic. Het kan je wat schijfruimte besparen, maar het kost je ook wat vrije schijfruimte tijdens het draaien, aangezien sommige opslagengines een geheel nieuwe kopie van de tabel maken, de kopie hernoemen en de oude tabel verwijderen. Het is in ieder geval onwaarschijnlijk dat het enige betekenisvolle invloed zal hebben op het geheugenverbruik.