我有类似的错误，今天复制数据库(MySQL服务器已经离开…)，但当我试图重新启动MySQL。服务器重启出错

ERROR! The server quit without updating PID ...

我是这样解决的: 我打开Applications/Utilities/并运行Activity Monitor

 quit mysqld

然后就能解决误差问题了

mysql.server restart

我正在做一些大型的计算，涉及到mysql连接停留很长时间和大量的数据。我正面临这个“Mysql走开的问题”。所以我试着优化查询，但这并没有帮助我，然后我增加了mysql变量限制，默认设置为较低的值。

wait_timeout max_allowed_packet

对于任何适合你的限制，它应该是任何数字* 1024(字节)。您可以使用'mysql -u username - p'命令登录到终端，并可以检查和更改这些变量限制。

如果您的数据包括BLOB数据:

请注意，从命令行导入数据似乎会阻塞在BLOB数据上，导致'MySQL server has gone away'错误。

为了避免这种情况，重新创建mysqldump，但是使用——hex-blob标记:

http://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_hex-blob

这将写出数据文件与十六进制值，而不是二进制之间的其他文本。

PhpMyAdmin也有选项“转储十六进制符号的二进制列(例如，“abc”变成0x616263)”，这工作得很好。

请注意，存在一个长期存在的错误(截至2015年12月)，这意味着GEOM列不能转换: 备份一个表几何列使用mysqldump? 所以使用像PhpMyAdmin这样的程序似乎是唯一的解决方案(上面提到的选项可以正确地转换GEOM列)。

如果需要很长时间才能失败，则扩大wait_timeout变量。

如果它马上失败，放大max_allowed_packet变量;如果它仍然不工作，确保命令是有效的SQL。我的书有未转义的引号，把一切都搞砸了。

此外，如果可行，可以考虑将单个SQL命令的插入数量限制为1000。您可以创建一个脚本，通过重新引入INSERT…每n个插入部分。

如果增加max_allowed_packet没有帮助。

当我通过Sequel Pro将.sql文件导入我的数据库时，我得到了和你一样的错误。

在将max_allowed_packet提高到512M后，错误仍然存在，所以我在命令行中运行导入:

mysql --verbose -u root -p DatabaseName < MySQL.sql

它给出了以下错误:

ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled

我发现了一些有用的StackOverflow问题:

在从SQL转储恢复数据库时启用二进制模式 Mysql错误:ASCII '\0'当导入sql文件在linux服务器上

在我的情况下，我的.sql文件有点损坏。我们得到的MySQL转储是两个zip文件，需要连接在一起，然后解压缩。我认为解压一开始就中断了，留下了一些奇怪的字符和编码。获得一个新的MySQL转储并正确地解压缩它对我来说很有效。

只是想在这里添加这个，以防其他人发现增加max_allowed_packet变量没有帮助。

确保mysqld进程不会因为systemd这样的服务管理器而重新启动。

我在《流浪》中遇到过这个问题。配置调整没有帮助。原来这是系统杀死我的服务每次当它占用太多的内存。