Den första delen av svaret är de goda nyheterna... att mysqlcheck -o är inte mer sannolikt att skada din databas än att OPTIMIZE TABLE körs på varje bord, för det är allt det gör. Det är ett bekvämlighetsverktyg som loggar in på servern, hämtar en lista över tabellerna och itererar genom dem och skickar en OPTIMIZE TABLE fråga till servern för ett bord åt gången tills det är klart.
Nu, några dåliga nyheter. Om du har latent korruption i dina tabellutrymmen, OPTIMIZE TABLE kan stöta på det, så du bör vara säker på att du är beredd på den möjligheten, med säkerhetskopior och en återställningsplan. Chansen för detta är ganska liten, men det är ett möjligt resultat.
Värre nyheter:skäller nästan säkert upp i fel träd.
Att köra Apache och MySQL tillsammans på samma maskin med betydande trafik -- eller betydande trafikvariationer -- strider mot bästa praxis och är ett recept på problem, eftersom båda tjänsterna tenderar att öka sin minnesförbrukning under belastning, och om databasen är stödet lagra för webbplatsdata, då tenderar ökad belastning att inträffa på båda tjänsterna samtidigt.
Se mitt svar på InnoDB Crash Post Mortem på Databas Administrators Stack Exchange och Varför är Apache Running Wild och Killing MySQL på serverfel för noggrann bevakning av detta ganska vanliga problem, där MySQL är offret, mer än något annat.
Observera att det inte spelar någon roll om du använder InnoDB eller inte. Databasåterställningsposterna i MySQL-felloggen kommer att vara lite annorlunda, men den döda giveawayen är denna:föregås av inget misstänkt alls, säger MySQL-felloggen:
mysqld_safe Number of processes running now: 0
Meddelanden som följer efter det tolkas ofta som att MySQL "kraschar", men det är inte vad som händer... Det har dödats. MySQL kan till och med vägra starta om, tills Apache lugnar ner sig eller startas om, eller servern startas om. Återigen, från felloggen kan du eller kanske inte se något i stil med detta:
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
Kontrollerar /var/log/syslog eller /var/log/messages (beroende på vilken distro du kör) kommer att visa dig det verkliga problemet.
$ sudo egrep 'kernel|oom' /var/log/syslog
...eller meddelanden... bör avslöja ett antal poster som börjar ungefär så här:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache blir så minneshungrig att systemet riskerar övergripande instabilitet, så "något" offras. Det där "något" är sannolikt MySQL Server-demonen, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL kommer vanligtvis att försöka starta om på egen hand, och för allt du vet kan detta också hända ibland... men såvida inte Apaches minneskrav försvinner snabbt, kommer MySQL inte att tillåtas begära tillräckligt med minne från systemet, och kommer att ge upp.
Att optimera borden har sina giltiga tillämpningar... men i det här fallet, om jag har identifierat ditt problem korrekt, skulle det vara mycket jämförbart med att arrangera om solstolarna på det sjunkande skeppet Titanic. Det kan spara lite diskutrymme för dig, men det kommer också att kosta dig lite ledigt diskutrymme när du kör eftersom vissa lagringsmotorer gör en helt ny kopia av tabellen, döper sedan om kopian och tar bort den gamla tabellen. I vilket fall som helst är det osannolikt att det har någon meningsfull inverkan på minnesförbrukningen.