当我试图获取一个大的SQL文件(一个大的INSERT查询)时,我得到这个错误。

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

表中没有任何内容被更新。我尝试了删除和恢复表/数据库,以及重新启动MySQL。这些都不能解决问题。

这是我的最大数据包大小:

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

下面是文件大小:

$ ls -s file.sql 
79512 file.sql

当我尝试另一种方法时……

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

当前回答

您还可以以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';

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

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

其他回答

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

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

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

如果这些答案都不能解决你的问题,我通过删除表,并以这种方式自动创建它们来解决它:

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

然后只需将此备份与您的db一起使用,它将删除并重新创建您需要的表。

然后你只备份数据,然后做同样的事情,它就会工作。

max_allowed_packet=64M

在my.cnf文件中添加这一行可以解决我的问题。

当列有大值时,这很有用,这会导致问题,你可以在这里找到解释。

在Windows上,这个文件位于:C:\ProgramData\MySQL\MySQL Server 5.6” Linux操作系统(Ubuntu):“/etc/mysql”

我在第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

当您创建的SCHEMA的COLLATION与转储中使用的不同时,也会出现此错误消息。因此,如果转储包含

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

你也应该在SCHEMA排序中反映这一点:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

我一直在模式中使用utf8mb4_general_ci,因为我的脚本来自一个新的V8安装,现在在旧5.7上加载一个DB崩溃了,几乎把我逼疯了。

所以,也许这能帮你节省一些令人沮丧的时间……: -)

(MacOS 10.3, mysql 5.7)