Първата част от отговора е добрата новина... че mysqlcheck -o не е по-вероятно да навреди на вашата база данни, отколкото при изпълнение на OPTIMIZE TABLE на всяка маса, защото това е всичко, което прави. Това е удобна помощна програма, която влиза в сървъра, извлича списък с таблиците и итерира през тях, изпращайки OPTIMIZE TABLE заявка към сървъра за една таблица в даден момент, докато приключи.
Сега малко лоши новини. Ако имате латентна корупция във вашите пространства за таблици, OPTIMIZE TABLE може да се сблъскате с него, така че трябва да сте сигурни, че сте подготвени за тази възможност, с резервни копия и план за възстановяване. Шансовете за това са доста малки, но е един възможен резултат.
По-лоша новина:почти сигурно лаят на грешното дърво.
Изпълняването на Apache и MySQL заедно на една и съща машина със значителен трафик - или значителна вариация на трафика - е в противоречие с най-добрите практики и е рецепта за проблеми, тъй като и двете услуги са склонни да увеличават консумацията на памет при натоварване и ако базата данни е подкрепата съхранява за данни от уеб сайт, тогава повишеното натоварване обикновено се случва и на двете услуги едновременно.
Вижте моя отговор на InnoDB Crash Post Mortem на администратори на база данни Stack Exchange и Защо Apache работи диво и убива MySQL при грешка на сървъра за задълбочено отразяване на този доста често срещан проблем, където MySQL е жертвата, повече от всичко.
Имайте предвид, че няма значение дали използвате InnoDB или не. Записите за възстановяване на базата данни в регистъра за грешки на MySQL ще бъдат малко по-различни, но мъртвото раздаване е следното:предшествано от нищо подозрително, регистрационният файл за грешки на MySQL казва:
mysqld_safe Number of processes running now: 0
Следващите съобщения често се тълкуват погрешно като MySQL "срив", но това не се случва... Убито е. MySQL може дори да откаже да се рестартира, докато Apache не се успокои или не бъде рестартиран, или сървърът не се рестартира. Отново, от регистъра на грешките може да видите или не може допълнително да видите нещо подобно:
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
Проверка на /var/log/syslog или /var/log/messages (в зависимост от това коя дистрибуция използвате) ще ви покаже истинския проблем.
$ sudo egrep 'kernel|oom' /var/log/syslog
...или съобщенията... трябва да разкрият редица записи, започващи нещо като това:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache става толкова гладен за памет, че системата е изложена на риск от цялостна нестабилност, така че „нещо“ се жертва. Това "нещо" вероятно ще бъде демонът на MySQL Server, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL обикновено се опитва да се рестартира сам и както знаете, това може да се случва понякога също... но освен ако изискванията на паметта на Apache не спаднат бързо, MySQL няма да може да поиска достатъчно памет от системата и ще откажи се.
Оптимизирането на масите има своите валидни приложения... но в този случай, ако съм идентифицирал проблема ви правилно, би било много сравнимо с пренареждането на шезлонги на потъващия кораб Титаник. Това може да ви спести малко дисково пространство, но също така ще ви струва малко свободно дисково пространство, докато работите, тъй като някои машини за съхранение правят изцяло ново копие на таблицата, след което преименуват копието и изтриват старата таблица. Във всеки случай е малко вероятно това да окаже съществено влияние върху консумацията на памет.
