`mysqlcheck`能否在不损坏数据库的情况下帮助我解决数据库问题？

背景

我有一个Drupal站点，其数据库由phpmyadmin管理。数据库的大小超过1500个表。我在速度方面遇到了很大的问题，正在寻找一个好的解决方案。该数据库已有2.5-3年历史，从未进行过维护（据我所知）

研究

我一直在试图找到一种加速的方法，一切都让我回到了数据库的纯尺寸。我遇到了命令

OPTIMIZE TABLE
tbl_name [, tbl_name] ...

女巫很快就把我带到了更强大的地方

mysqlcheck -o <db_schema_name>

mysqlcheck-o

我没有可以使用此命令的测试区域，因为我们只有一个数据库。我知道在我的数据库上运行这个命令会花费很长时间，因为数据库太大，可能需要几天的时间

推理

我之所以要使用它，是因为MySQL似乎每天都会关闭或崩溃。在phpmyadmin上我看到了这个

它只运行了9个小时，自从1个月前开始工作以来，我还没有关掉它。它似乎永远不会超过15小时

状态变量

这是将值显示为警报的状态变量列表，我希望通过mysqlcheck修复其中一些

结论

---

我想知道在数据库上运行mysqlcheck是否会导致任何问题或损坏数据库中的任何数据。了解这样的手术需要多长时间也很方便。

答案的第一部分是好消息。。。与在每个表上运行

optimizetable

相比，

mysqlcheck-o

不太可能对数据库造成损害，因为这就是它所做的一切。这是一个方便实用程序，它可以登录到服务器，获取表的列表，并对它们进行迭代，每次向服务器发送一个表的

optimizetable

查询，直到完成为止

现在，有些坏消息。如果您的表空间中存在潜在的损坏，

OPTIMIZE TABLE

可能会遇到这种情况，所以您应该确定，您已经准备好了备份和恢复计划。这种可能性相当渺茫，但这是一种可能的结果

更糟糕的消息是：我们几乎肯定是找错了方向

在同一台计算机上同时运行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

kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0

检查

/var/log/syslog

或

/var/log/messages

（取决于您运行的发行版）将显示真正的问题

$ sudo egrep 'kernel|oom' /var/log/syslog

…或消息。。。应该显示一些条目，开头类似于：

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

kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0

Apache非常需要内存，以至于系统面临整体不稳定的风险，因此牺牲了“某些东西”。“某物”很可能是MySQL服务器守护程序，

mysqld

kernel: Out of memory: Killed process 3044, UID 27, (mysqld)

MySQL通常会尝试自己重新启动，你知道，这也可能偶尔发生。。。但除非Apache的内存需求迅速下降，否则MySQL将不允许从系统请求足够的内存，并将放弃

---

优化表有其有效的应用程序。。。但是，在这种情况下，如果我正确地确定了你的问题，这将非常类似于在沉没的泰坦尼克号上重新布置甲板椅。它可能会为您节省一些磁盘空间，但在运行时也会占用一些空闲磁盘空间，因为某些存储引擎会创建表的全新副本，然后重命名副本并删除旧表。无论如何，它不太可能对内存消耗产生任何有意义的影响。

答案的第一部分是好消息。。。与在每个表上运行

optimizetable

相比，

mysqlcheck-o

不太可能对数据库造成损害，因为这就是它所做的一切。这是一个方便实用程序，它可以登录到服务器，获取表的列表，并对它们进行迭代，每次向服务器发送一个表的

optimizetable

查询，直到完成为止

现在，有些坏消息。如果您的表空间中存在潜在的损坏，

OPTIMIZE TABLE

可能会遇到这种情况，所以您应该确定，您已经准备好了备份和恢复计划。这种可能性相当渺茫，但这是一种可能的结果

更糟糕的消息是：我们几乎肯定是找错了方向

在同一台计算机上同时运行Apache和MySQL，并带来显著的流量（或流量变化），这违反了最佳做法，也会导致问题，因为这两种服务在负载下都会增加内存消耗，如果数据库是网站数据的后备存储，然后，两个服务上的负载往往会同时增加

请参阅我对这个相当常见的问题的回答和详细介绍，MySQL是其中的关键