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

Question

背景

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

研究

我一直在努力寻找一种方法来加快速度，但一切都让我回到了数据库的纯粹大小。我遇到了命令

OPTIMIZE TABLE
tbl_name [, tbl_name] ...

女巫很快带我走向更强大的地方

mysqlcheck -o <db_schema_name>

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

推理

我想使用它的原因是因为 MySQL 似乎每天都会关闭或崩溃。在 phpmyadmin 上我看到了这个

它只运行了 9 个小时，自从我 1 个月前开始处理这个问题以来我还没有关闭它。似乎永远不会超过 15 小时。

状态变量

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

结论

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

Answer 1

答案的第一部分是好消息...mysqlcheck -o 不会比在每个表上运行 OPTIMIZE TABLE 更可能损害您的数据库，因为这就是它所做的一切。它是一个方便的实用程序，可以登录到服务器，获取表列表，并遍历它们，向服务器一次处理一个表，直到完成。

现在，一些坏消息。如果您的表空间中有潜在的损坏，OPTIMIZE TABLE 可能会遇到它，因此您应该确定您已经为这种可能性做好了准备，包括备份和恢复计划。发生这种情况的可能性很小，但是一种可能的结果。

更糟糕的消息:几乎可以肯定是找错了树。

在同一台机器上同时运行 Apache 和 MySQL 并且流量很大——或者流量变化很大——有悖于最佳实践并且会产生问题，因为这两种服务往往会增加它们在负载下的内存消耗，如果数据库是网站数据的后备存储，那么增加的负载往往会同时发生在这两个服务上。

请参阅我对 InnoDB Crash Post Mortem on Database Administrators Stack Exchange 的回答和 Why is Apache Running Wild and Killing MySQL on Server Fault为了彻底覆盖这个相当普遍的问题，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 服务器守护进程 mysqld。

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

MySQL 通常会尝试自行重启，据您所知，这可能偶尔会发生......但是除非 Apache 的内存需求迅速下降，否则 MySQL 将不允许从系统请求足够的内存, 并会放弃。

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