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

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

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

一般的错误是:

错误:2006 (CR_SERVER_GONE_ERROR) - MySQL服务器已经离开

意味着客户端不能向服务器发送问题。

mysql进口

在您通过mysql导入数据库文件的特定情况下，这很可能意味着SQL文件中的一些查询太大而无法导入，并且它们无法在服务器上执行，因此客户端在第一次出现错误时失败。

所以你有以下几种可能性:

为mysql添加force选项(-f)以继续执行其余的查询。 如果数据库有一些与缓存相关的大型查询，这是非常有用的。 增加服务器配置中的max_allowed_packet和wait_timeout(例如~/.my.cnf)。 使用——skip-extended-insert选项来分解大型查询来转储数据库。然后重新导入。 尝试为mysql应用——max-allowed-packet选项。

常见的原因

一般来说，这个错误可能意味着以下几种情况:

a query to the server is incorrect or too large, Solution: Increase max_allowed_packet variable. Make sure the variable is under [mysqld] section, not [mysql]. Don't afraid to use large numbers for testing (like 1G). Don't forget to restart the MySQL/MariaDB server. Double check the value was set properly by: mysql -sve "SELECT @@max_allowed_packet" # or: mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'" You got a timeout from the TCP/IP connection on the client side. Solution: Increase wait_timeout variable. You tried to run a query after the connection to the server has been closed. Solution: A logic error in the application should be corrected. Host name lookups failed (e.g. DNS server issue), or server has been started with --skip-networking option. Another possibility is that your firewall blocks the MySQL port (e.g. 3306 by default). The running thread has been killed, so retry again. You have encountered a bug where the server died while executing the query. A client running on a different host does not have the necessary privileges to connect. And many more, so learn more at: B.5.2.9 MySQL server has gone away.

调试

以下是一些专家级调试思路:

检查日志，例如: sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error") 通过mysql, telnet或ping函数(例如PHP中的mysql_ping)测试您的连接。 使用tcpdump嗅探MySQL通信(不适用于套接字连接)，例如: Sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql |字符串 在Linux操作系统上，请使用strace。在BSD/Mac上使用dtrace/dtruss，例如: Sudo dtruss -a -fn mysqld 2>&1 参见:开始使用DTracing MySQL

了解更多如何调试MySQL服务器或客户端:26.5调试和移植MySQL。

作为参考，请检查sql-common/client.c文件中负责抛出客户端命令CR_SERVER_GONE_ERROR错误的源代码。

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
          arg, arg_length))
{
  set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
  goto end;
}

我在第97行解决了错误error 2006 (HY000): MySQL服务器已经离开，并成功迁移了一个>5GB sql文件，按顺序执行以下两个步骤:

创建了其他人推荐的/etc/my.cnf，内容如下: (mysql) Connect_timeout = 43200 max_allowed_packet = 2048M net_buffer_length = 512M debug-info = TRUE 附加标志——force——wait——重新连接到命令(即mysql -u root -p -h localhost my_db < file. exe)。SQL——verbose——force——wait——reconnect)。

重要提示:执行这两个步骤都是必要的，因为如果我不费心对/etc/my.cnf文件进行更改，也不附加这些标志，导入后会丢失一些表。

系统使用:OSX El Capitan 10.11.5;mysql version 14.14 distribub 5.5.51 for osx10.8

您还可以以root(或SUPER特权)身份登录到数据库并执行该操作

set global max_allowed_packet=64*1024*1024;

不需要重新启动MySQL。注意，你应该修复my.cnf文件，就像在其他解决方案中概述的那样:

[mysqld]
max_allowed_packet=64M

重新启动MySQL后确认更改:

show variables like 'max_allowed_packet';

您也可以使用命令行，但这可能需要更新启动/停止脚本，这些脚本可能无法在系统更新和补丁中保存。

根据要求，我在这里添加了我自己的答案。很高兴看到它工作!

由于某些原因，全局更新和my.cnf设置对我不起作用。将max_allowed_packet值直接传递给客户端工作在这里:

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

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