对我来说，它有助于修复一个innodb表的损坏的索引树。我用这个命令本地化了这样一个表

mysqlcheck -uroot --databases databaseName 

结果

mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE ...

如下所示，我只能从mysqld日志/var/log/mysqld.log中看到哪个表造成了问题。

FIL_PAGE_PREV links 2021-08-25T14:05:22.182328Z 2 [ERROR] InnoDB: Corruption of an index tree: table `database`.`tableName` index `PRIMARY`, father ptr page no 1592, child page no 1234'

mysqlcheck命令并没有修复它，但帮助揭示了它。 最终，我通过mysql命令行中一个常规的mysql命令来修复它

OPTIMIZE table theCorruptedTableNameMentionedAboveInTheMysqld.log

以防这能帮助到任何人:

当我打开和关闭将从应用程序的几个部分调用的函数中的连接时，我得到了这个错误。 我们获得了太多的连接，所以我们认为重用现有的连接或将其丢弃并创建一个新的连接可能是一个好主意，如下所示:

public static function getConnection($database, $host, $user, $password){
    if (!self::$instance) {
        return self::newConnection($database, $host, $user, $password);
    } elseif ($database . $host . $user != self::$connectionDetails) {
        self::$instance->query('KILL CONNECTION_ID()');
        self::$instance = null;
        return self::newConnection($database, $host, $user, $password);
    }
    return self::$instance;
}

事实证明，我们在kill方面做得有点太彻底了，所以在旧连接上做重要事情的进程永远无法完成他们的业务。 所以我们去掉了这些线

self::$instance->query('KILL CONNECTION_ID()');
self::$instance = null;

由于机器的硬件和设置允许，我们增加了服务器上允许的连接数

max_connections = 500

到我们的配置文件。这解决了我们现在的问题，我们学到了一些关于杀死mysql连接。

我遇到过这种情况很多次，我通常发现答案是max_allowed_packet的默认设置非常低。

在/etc/my.cnf(在[mysqld]下)中将它提升到8或16M通常可以修复它。(MySql 5.7的默认值是4194304，也就是4MB。)

[mysqld]
max_allowed_packet=16M

注意:如果该行不存在，只需创建该行

注意:这可以在服务器运行时设置。

注意:在Windows上，您可能需要使用ANSI而不是UTF-8编码保存my.ini或my.cnf文件。

使用set global max_allowed_packet=104857600。这将它设置为100MB。

我在DigitalOcean Ubuntu服务器上也出现了同样的错误。

我尝试改变max_allowed_packet和wait_timeout设置，但他们都没有修复它。

原来我的服务器内存不足。我添加了一个1GB的交换文件，这解决了我的问题。

用free -h检查你的内存，看看这是否是导致它的原因。

如果你知道你要离线一段时间，你可以关闭连接，进行处理，重新连接并撰写报告。

对于Vagrant Box，请确保为该Box分配了足够的内存

config.vm.provider "virtualbox" do |vb|
  vb.memory = "4096"
end