Den første del af svaret er den gode nyhed... at mysqlcheck -o er ikke mere tilbøjelige til at skade din database, end at OPTIMIZE TABLE kører på hvert bord, fordi det er alt, det gør. Det er et bekvemmelighedsværktøj, der logger ind på serveren, henter en liste over tabellerne og gentager dem og sender en OPTIMIZE TABLE forespørg på serveren for et bord ad gangen, indtil det er færdigt.
Nu nogle dårlige nyheder. Hvis du har latent korruption i dine tablespaces, OPTIMIZE TABLE kan løbe ind i det, så du skal være sikker på, at du er forberedt på den mulighed, med sikkerhedskopier og en gendannelsesplan. Chancerne for dette er ret lille, men det er et muligt udfald.
Værre nyhed:Gøer næsten helt sikkert op i det forkerte træ.
At køre Apache og MySQL sammen på den samme maskine med betydelig trafik - eller betydelig trafikvariation - er imod bedste praksis og er en opskrift på problemer, fordi begge tjenester har en tendens til at øge deres hukommelsesforbrug under belastning, og hvis databasen er baggrunden gemme til webstedsdata, så har øget belastning en tendens til at forekomme på begge tjenester på samme tid.
Se mit svar på InnoDB Crash Post Mortem på Database Administrators Stack Exchange og Hvorfor løber Apache vildt og dræber MySQL på serverfejl for grundig dækning af dette ret almindelige problem, hvor MySQL er offeret, mere end noget andet.
Bemærk, at det er ligegyldigt, om du bruger InnoDB eller ej. Databasegendannelsesindtastningerne i MySQL-fejlloggen vil være lidt anderledes, men den døde giveaway er denne:forud for intet mistænkeligt siger MySQL-fejlloggen:
mysqld_safe Number of processes running now: 0
Beskederne efter, at man bliver ofte misfortolket som MySQL "crashing", men det er ikke det, der sker... Det er blevet dræbt. MySQL kan endda nægte at genstarte, indtil Apache falder til ro eller genstartes, eller serveren genstartes. Igen, fra fejlloggen kan du muligvis også se noget som dette:
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
Kontrollerer /var/log/syslog eller /var/log/messages (afhængigt af hvilken distro du kører) vil vise dig det virkelige problem.
$ sudo egrep 'kernel|oom' /var/log/syslog
...eller beskeder... bør afsløre et antal poster, der begynder noget som dette:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache bliver så hukommelsessulten, at systemet er i fare for generel ustabilitet, så "noget" bliver ofret. Det "noget" er sandsynligvis MySQL Server-dæmonen, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL vil normalt forsøge at genstarte af sig selv, og for alt hvad du ved, kan dette også ske en gang imellem... men medmindre Apaches hukommelseskrav falder hurtigt, vil MySQL ikke have lov til at anmode om tilstrækkelig hukommelse fra systemet, og vil give op.
Optimering af bordene har sine gyldige applikationer... men i dette tilfælde, hvis jeg har identificeret dit problem korrekt, ville det i høj grad kunne sammenlignes med at omarrangere liggestolene på det synkende skib Titanic. Det kan spare dig for noget diskplads, men det vil også koste dig noget ekstra diskplads, mens du kører, da nogle lagermotorer laver en helt ny kopi af tabellen, og derefter omdøber kopien og sletter den gamle tabel. Under alle omstændigheder er det usandsynligt, at det har nogen meningsfuld indvirkning på hukommelsesforbruget.