我尝试了以上所有的解决方案，都失败了。

我最终使用-h 127.0.0.1，而不是使用默认的var/run/mysqld/mysqld.sock。

解决方案是增加选项文件中[mysqld]标记下的wait_timeout和connect_timeout参数的值。

我必须恢复一个400MB的mysql备份，这对我来说是有效的(我下面使用的值有点夸张，但你知道的):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

引用

这是一个比较罕见的问题，但我看到过，如果有人复制了整个/var/lib/mysql目录，作为将他们的DB迁移到另一个服务器的一种方式。它不起作用的原因是数据库正在运行并使用日志文件。如果/var/log/mysql.中有日志，它有时会不起作用解决方案是复制/var/log/mysql文件。

如果它正在重新连接并获得连接ID 2，那么服务器几乎肯定已经崩溃了。

联系服务器管理员，让他们诊断问题。任何非恶意SQL都不应该导致服务器崩溃，mysqldump的输出当然也不应该。

这可能是由于服务器管理员犯了一些较大的操作错误，例如分配的缓冲区大小大于体系结构的地址空间限制，或者大于虚拟内存容量。MySQL错误日志可能会有一些相关的信息;无论如何，如果他们有能力，他们将会监督这一点。

对于amazon RDS(这是我的情况)，您可以将max_allowed_packet参数值更改为任何字节的数值，这对于您可能拥有的任何插入中的最大数据有意义(例如:如果您在插入中有一些50mb blob值，则将max_allowed_packet设置为64M = 67108864)，在一个新的或现有的参数组中。然后将参数组应用到MySQL实例(可能需要重新启动实例)。

您可以增加最大允许包数

SET GLOBAL max_allowed_packet=1073741824;

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet