当我把mysql降级到更兼容的版本时，它为我工作了。
可能还需要更新驱动程序。

我找到了解决办法，如果不是解决办法的话。使用linux获取sed实用程序，并运行我在前面的评论中提到的两个sed命令。另外，我需要使用mysqldump选项： --set-gtid-purged=OFF

我也面临着类似的问题。只是去掉了那个词 NO_AUTO_CREATE_USER 通过使用 find & replace mysql工作台中的选项，执行得很好。

最近，我从mysql workbench 6.1ce导出数据库，然后尝试将其导入mysql workbench 8.0.11的更新版本后，也遇到了这个问题。每个都是用社区服务器安装程序msi安装的。
在做了一些搜索之后，我在mysql网站上发现了这个bug报告：restaure dump是在8.0.11上用5.7.22创建的
对我有效的修复方法是手动检查转储文件并删除以下语句：
“no\u auto\u create\u user”位于转储文件中每个例程转储的上方。语句删除图像示例
在我这样做之后，我收到了错误
第318行出现错误1418（hy000）：此函数没有确定性，没有sql，或者在其声明中读取sql数据，并且启用了二进制日志记录（您可能希望使用不太安全的log\u bin\u trust\u function\u creators变量）
但是在提到这个已回答的问题之后：这个函数没有确定性，没有sql，或者在它的声明中读取sql数据，二进制日志记录被启用，只需输入： SET GLOBAL log_bin_trust_function_creators = 1; 在mysql中，命令行客户机解决了这个问题，并最终允许我正确地导入包含所有转储表、数据、例程和函数的数据库。
希望这能为其他人节省一些时间。

Bug已修复

重要的变化：从MySQL5.7服务器导入转储到运行MySQL8.0的服务器常常失败 ER_WRONG_VALUE_FOR_VAR 当使用8.0服务器不支持的sql模式时。这种情况可能经常发生，因为 NO_AUTO_CREATE_USER 在MySQL5.7中默认启用，但在MySQL8.0中不支持。
服务器在这种情况下的行为现在取决于 pseudo_slave_mode 系统变量。如果为false，服务器将拒绝模式设置 ER_UNSUPPORTED_SQL_MODE . 如果 pseudo_slave_mode 如果为true，服务器将忽略不支持的模式并发出警告。注意mysqlbinlog设置 pseudo_slave_mode 在执行任何sql之前设置为true(臭虫#90337，臭虫#27828236）
来源：mysql发行说明。

验证这一点：

我连接到mysql，然后在默认情况下选择我的模式，在workbench sql选项卡中运行以下命令：

SET pseudo_slave_mode = true;
SET @@SESSION.pseudo_slave_mode = true;

为了确保工作正常，我在“其他”选项卡中使用其他命令进行了验证：

SHOW VARIABLES;

它向我显示了变量列表，我通过键入ps来过滤它以找到 pseudo_slave_mode 变量

是的 pseudo_slave_mode 是 ON 现在（以前是什么时候 OFF )
然后我运行了.sql，它显示了 NO_AUTO_CREATE_USER 再次出错，但这次它创建了.sql文件中所需的所有内容
然后，我将架构转储到另一个sql文件以验证它： mysqldump -u root -p --no-data --routines my_database > schema.sql 一切都很好。这一次它用一个修改过的 sql_mode 我希望这能对你有所帮助。