变量＆＃39; sql_mode＆＃39;无法设置为＆＃39; NO_AUTO_CREATE_USER＆＃39;

Question

我正在使用MySQL Workbench 8.0。我试图将测试数据转储到DB，包括所有表，存储过程和带数据的视图。

当我尝试导入它时，导入导致一个错误，错误是

  

变量＆＃39; sql_mode＆＃39;无法设置为＆＃39; NO_AUTO_CREATE_USER＆＃39;   exitcode 1操作失败

如果我检查数据库，导入后也只有表格，但根本没有存储过程。

如何解决这个问题？

Answer 1

从MySQL Workbench 6.1 CE导出我的数据库，然后尝试将其导入更新版本的MySQL WorkBench 8.0.11后，我最近遇到了这个问题。每个都安装了社区服务器安装程序msi。

在做了一些搜索后，我在MySQL网站上看到了这个错误报告： Restaure dump created with 5.7.22 on 8.0.11

对我有用的修复方法是手动浏览我的转储文件并删除语句：

  

'NO_AUTO_CREATE_USER'位于转储文件中的每个例程转储之上。   Statement to remove image example

我这样做后收到了错误

  

ERROR 1418（HY000）第318行：此函数在其声明中没有DETERMINISTIC，NO SQL或READS SQL DATA，并且启用了二进制日志记录（您可能想要使用不太安全的log_bin_trust_function_creators变量）

但在提到这个回答的问题之后： This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled 只需输入：

SET GLOBAL log_bin_trust_function_creators = 1;

在 MySQL命令行客户端解决了这个问题，最后允许我使用所有转储的表，数据，例程和函数正确导入我的数据库。

希望这能节省一些时间。

Answer 2

我也面临类似的问题。只需使用mysql工作台中的NO_AUTO_CREATE_USER和find选项从导入脚本中删除这些单词replace，它就可以很好地执行。

Answer 3

查找和替换的最佳方法。 找到 NO_AUTO_CREATE_USER 并在不打开文件的情况下将其替换为空。

Linux sed 实用程序是最好的选择，如果 *.sql 文件太大而无法打开。

sed -i 's/FIND_TEXT/REPLACE_TEXT/' file.sql
sed -i 's/NO_AUTO_CREATE_USER//' file.sql

-i 代表 --in-place[=SUFFIX]

-s 代表 --separate

Answer 4

固定的错误

重要更改：在以下情况下，将转储从 MySQL 5.7 服务器导入运行 MySQL 8.0 的服务器通常会失败，ER_WRONG_VALUE_FOR_VAR使用了8.0服务器不支持的SQL模式。由于NO_AUTO_CREATE_USER在MySQL 5.7中是默认启用的，而在MySQL 8.0中是不受支持的，因此这种情况经常发生。

服务器在这种情况下的行为现在取决于pseudo_slave_mode系统变量的设置。如果为false，则服务器拒绝ER_UNSUPPORTED_SQL_MODE的模式设置。如果pseudo_slave_mode为true，则服务器将忽略不支持的模式并给出警告。请注意，在执行任何SQL之前， mysqlbinlog 会将pseudo_slave_mode设置为true。 （错误＃90337，错误＃27828236）

来源：MySQL release notes.

验证：

我连接到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 文件中所需的所有内容< / p>

然后我将架构转储到另一个sql文件中进行验证：

mysqldump -u root -p --no-data --routines my_database > schema.sql

一切都还好。这次，它使用修改后的sql_mode

进行了转储

我希望这对您有帮助。

Answer 5

在命令行中，--force 选项将导致 mysql 继续处理转储并忽略“NO_AUTO_CREATE_USER”（以及任何其他）错误。

您也可以在 MySQL Workbench 中启用此行为。见Continue SQL query even on errors in MySQL workbench。

Answer 6

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

Answer 7

当我将mysql降级到更兼容的版本时为我工作。

可能还可以更新驱动程序。

Answer 8

狄龙的回答对我有用，谢谢

MAC 操作系统：
sed -i old 's/\DEFINER=[^]*@[^]*//g' file_name.sql
sed 's/,NO_AUTO_CREATE_USER//g' -i file_name.sql

Linux：
sed 's/\sDEFINER=[^]*@[^]*//g' -i file_name.sql
sed 's/,NO_AUTO_CREATE_USER//g' -i file_name.sql

Mysql：
mysql> 设置全局 log_bin_trust_function_creators = 1;