Importing 1GO SQL File => ERROR 2013 (HY000) at line 23: Lost connection to MySQL server during query
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10646216/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Importing 1GO SQL File => ERROR 2013 (HY000) at line 23: Lost connection to MySQL server during query
提问by Anthony
Ive got to import 1go of sql data, i raised up the max_allowed_packet to 1100M to be sure.
我必须导入 1go 的 sql 数据，我将 max_allowed_packet 提高到 1100M 以确保。
So i use :
所以我使用：
My query
我的查询
mysql -u root -p -D mainbase < GeoPC_WO.sql
But 1 minute later it stops during the process and i get this error :
但是 1 分钟后它在此过程中停止，我收到此错误：
**ERROR 2013 (HY000) at line 23: Lost connection to MySQL server during query
**Lost connection to MySQL server during query****
采纳答案by Adrian Cornish
Possible that you have some large insert statements that are bigger than you max size. Check your /etc/mysql/my.cnf file or wherever it is. Cannot remember what the default is - but setting it to something large like below may help.
可能您有一些大于最大大小的大型插入语句。检查您的 /etc/mysql/my.cnf 文件或它在哪里。不记得默认值是什么 - 但将其设置为如下所示的大值可能会有所帮助。
This is one option
这是一种选择
[mysqld]
max_allowed_packet = 16M
And maybe the other way
也许另一种方式
[mysqldump]
max_allowed_packet = 16M
回答by bakytn
I had exactly the same problem. After 1 hour of struggling I resolved this by setting
我遇到了完全相同的问题。经过 1 小时的努力，我通过设置解决了这个问题
net_write_timeout
to a higher value (in my situation it's 300)
到更高的值（在我的情况下是300）
回答by nightcoder
In my case the problem ("Lost connection to MySQL Server during query") was in a corrupted dump file or in the misbehaving HDDs:
在我的情况下，问题（“在查询期间与 MySQL 服务器的连接丢失”）出在损坏的转储文件或行为不端的 HDD 中：
First, I made a dump on the main server and then copied that dump to the replication server. But it seems the replication server had some problems with its HDDs and the dump became corrupted, i.e. MD5 of the original dump file on the main server was different from MD5 of the dump copy on the replication server.
首先，我在主服务器上进行了转储，然后将该转储复制到复制服务器。但似乎复制服务器的硬盘出现了一些问题，并且转储已损坏，即主服务器上原始转储文件的 MD5 与复制服务器上的转储副本的 MD5 不同。
回答by Gustavo Magallanes-Guijón
You can try with this:
你可以试试这个：
First:
第一的：
sudo /etc/init.d/mysql stop
Then you should edit this file:
然后你应该编辑这个文件：
sudo vi /etc/mysql/my.cnf
Add the following line to the [mysqld] section:
将以下行添加到 [mysqld] 部分：
innodb_force_recovery = 4
Finally:
最后：
sudo /etc/init.d/mysql start
(innodb_force_recovery force the InnoDB storage engine to start. The value 4 mean your data files can be corrupted. For more information you can visit: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html)
（innodb_force_recovery 强制启动 InnoDB 存储引擎。值 4 表示您的数据文件可能被损坏。有关更多信息，您可以访问：http: //dev.mysql.com/doc/refman/5.7/en/forcing-innodb-恢复.html）
Greetings.
你好。
回答by xManh
In my case it was because of the lack of RAM, I tried to import a 90MB zipped sql file to a 1GB RAM vps server and the error 2013 keep occured until I switched down the httpd service to release some memory and run the import command again and it was successful then.
就我而言，这是因为缺少 RAM，我尝试将 90MB 压缩的 sql 文件导入到 1GB RAM vps 服务器，并且错误 2013 一直出现，直到我关闭 httpd 服务以释放一些内存并再次运行导入命令然后就成功了。
