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

消除触发警告的错误是我的最终解决方案。我还改变了max_allowed_packet，这有助于较小的文件与错误。消除这些错误也会极大地加快这个过程。

我也有同样的问题，但改变my.ini/my.cnf文件下[mysqld]的max_allowed_packet。

添加一条线

max_allowed_packet=500M

现在重新启动MySQL服务，一旦你完成。

如何使用mysql客户端像这样:

mysql -h <hostname> -u username -p <databasename> < file.sql

解决方案是增加选项文件中[mysqld]标记下的wait_timeout和connect_timeout参数的值。

我必须恢复一个400MB的mysql备份，这对我来说是有效的(我下面使用的值有点夸张，但你知道的):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

引用

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

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

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

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