Der erste Teil der Antwort ist die gute Nachricht ... dass mysqlcheck -o schadet Ihrer Datenbank wahrscheinlich nicht mehr, als OPTIMIZE TABLE auszuführen auf jedem Tisch, denn das ist alles, was es tut. Es ist ein praktisches Dienstprogramm, das sich beim Server anmeldet, eine Liste der Tabellen abruft und sie durchläuft, wobei es eine OPTIMIZE TABLE sendet Abfrage an den Server für jeweils eine Tabelle, bis es fertig ist.
Nun, einige schlechte Nachrichten. Wenn Sie eine latente Beschädigung in Ihren Tablespaces haben, OPTIMIZE TABLE könnte darauf stoßen, also sollten Sie sicher sein, dass Sie mit Backups und einem Wiederherstellungsplan auf diese Möglichkeit vorbereitet sind. Die Chancen dafür sind ziemlich gering, aber es ist ein mögliches Ergebnis.
Schlimmere Neuigkeiten:bellen mit ziemlicher Sicherheit den falschen Baum an.
Das gemeinsame Ausführen von Apache und MySQL auf demselben Computer mit erheblichem Datenverkehr – oder erheblichen Datenverkehrsschwankungen – verstößt gegen Best Practices und ist ein Rezept für Probleme, da beide Dienste dazu neigen, ihren Speicherverbrauch unter Last zu erhöhen, und wenn die Datenbank die Unterstützung ist Website-Daten speichern, dann kommt es tendenziell zu einer erhöhten Last auf beiden Diensten gleichzeitig.
Siehe meine Antwort auf InnoDB Crash Post Mortem auf Database Administrators Stack Exchange und Warum läuft Apache wild und tötet MySQL auf Serverfehler für die gründliche Behandlung dieses ziemlich häufigen Problems, bei dem MySQL vor allem das Opfer ist.
Beachten Sie, dass es keine Rolle spielt, ob Sie InnoDB verwenden oder nicht. Die Datenbank-Wiederherstellungseinträge im MySQL-Fehlerprotokoll werden ein wenig anders sein, aber das entscheidende Zeichen ist Folgendes:Dem MySQL-Fehlerprotokoll steht nichts Verdächtiges voran:
mysqld_safe Number of processes running now: 0
Die darauf folgenden Meldungen werden oft als "Absturz" von MySQL missinterpretiert, aber das ist nicht der Fall ... Es wurde getötet. MySQL kann sogar einen Neustart verweigern, bis Apache sich beruhigt oder neu gestartet wird oder der Server neu gestartet wird. Auch hier können Sie im Fehlerprotokoll möglicherweise Folgendes sehen oder auch nicht:
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
Prüfen von /var/log/syslog oder /var/log/messages (je nachdem, welche Distribution Sie verwenden) zeigt Ihnen das eigentliche Problem.
$ sudo egrep 'kernel|oom' /var/log/syslog
... oder Nachrichten ... sollten eine Reihe von Einträgen enthalten, die ungefähr so beginnen:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache wird so speicherhungrig, dass das System insgesamt instabil zu werden droht, also wird „etwas“ geopfert. Dieses „Etwas“ ist wahrscheinlich der MySQL-Server-Daemon mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL wird normalerweise versuchen, von selbst neu zu starten, und soweit Sie wissen, kann dies gelegentlich auch passieren ... aber wenn die Speicheranforderungen von Apache nicht schnell abfallen, darf MySQL nicht genügend Speicher vom System anfordern, und wird es tun aufgeben.
Das Optimieren der Tische hat seine gültigen Anwendungen ... aber in diesem Fall, wenn ich Ihr Problem richtig identifiziert habe, wäre es sehr vergleichbar mit dem Umstellen der Liegestühle auf dem sinkenden Schiff Titanic. Es kann Ihnen etwas Speicherplatz sparen, aber es kostet Sie auch etwas freien Speicherplatz während der Ausführung, da einige Speicher-Engines eine völlig neue Kopie der Tabelle erstellen, dann die Kopie umbenennen und die alte Tabelle löschen. In jedem Fall ist es unwahrscheinlich, dass dies einen bedeutenden Einfluss auf den Speicherverbrauch hat.
