当我使用Mysql集群时，我遇到了这个错误，我不知道这个问题是否来自集群的使用。由于误差是完全相同的，所以在这里给出我的解。 得到这个错误是因为数据节点突然崩溃。但是当节点崩溃时，你仍然可以使用cmd得到正确的结果:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

mysqld也可以正常工作。所以一开始，我不明白是怎么回事。大约5分钟后，ndb_mgm结果显示没有数据节点工作。然后我意识到问题所在。因此，尝试重新启动所有的数据节点，然后mysql服务器恢复正常，一切正常。

但有一件事对我来说很奇怪，在我失去mysql服务器的一些查询后，当我使用cmd像show tables，我仍然可以得到像set中的33行(5.57秒)这样的返回信息，但没有表信息显示。

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

以防万一，检查你可以使用的变量

$> mysqladmin variables -u user -p 

这将显示当前变量，在本例中是max_allowed_packet，正如有人在另一个答案中所说，您可以临时设置它

mysql> SET GLOBAL max_allowed_packet=1072731894

在我的情况下，cnf文件没有考虑到，我不知道为什么，所以SET GLOBAL代码真的很有帮助。

当您创建的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)

如果你在Mac上，像我一样通过brew安装mysql，下面的方法是有效的。

Cp $(brew——prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

出处:对于自制mysql安装，my.cnf在哪里?

在/usr/local/etc/my.cnf文件中增加max_allowed_packet=1073741824 mysql。服务器重启

max_allowed_packet=64M

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

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

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