变量“sql_mode”不能设置为“NO_AUTO_CREATE_USER”的值

Posted 2023-03-21

【中文标题】变量“sql_mode”不能设置为“NO_AUTO_CREATE_USER”的值

【英文标题】：Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'

【发布时间】：2018-10-24 11:18:56

【问题描述】：

我正在使用 mysql Workbench 8.0。我正在尝试将测试数据转储到数据库，包括所有表、存储过程和数据视图。

当我尝试导入时，它说导入完成时出现一个错误，错误是

操作失败，退出代码 1

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

如何解决这个问题？

【问题讨论】：

您的文件很大吗？如果可能的话，您可以通过转储找到它尝试设置 NO_AUTO_CREATE_USER 值的位置，然后删除该部分

如果您可以访问 sed 实用程序，请尝试以下命令：sed -i 's/NO_AUTO_CREATE_USER//' mysqldump.sql 从转储文件中删除“NO_AUTO_CREATE_USER”文本，并将其替换为空。

@pbnelson 在执行此操作之前，您应该使用 grep 查找 NO_AUTO_CREATE_USER。因为如果您有更多选择，您还必须删除逗号。即我的dumpfle中有'NO_AUTO_CREATE_USER，NO_ENGINE_SUBSTITUTION'。

【参考方案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) at line 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 命令行客户端解决了这个问题，并最终允许我正确导入包含所有转储表、数据、例程和函数的数据库。

希望这可以节省其他人一些时间。

【讨论】：

这是答案，我希望有人将其标记为 - 这在这个问题的 Laravel 绑定版本中很难找到。我还要补充一点，如果您的备份文件很大（我的超过 200MB），它将在 MySQL Workbench 中基本上无法打开，它最终会打开但您将无法实际编辑它 - 使用类似 Visual Studio Code相反，它对我来说几乎是立即打开的，我能够为 NO_AUTO_CREATE_USER 查找和替换所有以修复导入错误。

我已经收到log_bin_trust_function_creators = 1;，但我仍然收到错误消息Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'

清除mysql5.7中的mysqldump文件sed -i 's/,NO_AUTO_CREATE_USER//g' path/da_name.sql

对于任何在查看一些旧 Laravel 版本时发现此内容的人，我从中删除 NO_AUTO_CREATE_USER 的相关文件只有 src/Illuminate/Database/Connectors/MySqlConnector.php。

@Leith 无需更改 vendor 文件夹中的文件，您可以编辑 config 文件夹中的 database.php 并将 strict 从 true 更改为 false。但是，您的评论确实让我找到了正确的解决方法！

【参考方案2】：

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

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

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

-i for --in-place[=SUFFIX]

-s for --separate

【参考方案3】：

我也遇到了类似的问题。刚刚通过在mysql工作台中使用find和replace选项从导入脚本中删除了NO_AUTO_CREATE_USER这个词，它执行得很好。

【参考方案4】：

已修复的错误

重要更改：将转储从 MySQL 5.7 服务器导入到运行 MySQL 8.0 的服务器通常会在 SQL 出现 ER_WRONG_VALUE_FOR_VAR 时失败使用了 8.0 服务器不支持的模式。这可能经常发生，因为NO_AUTO_CREATE_USER 在 MySQL 5.7 中默认启用，但在 MySQL 8.0 中不支持。

服务器在这种情况下的行为现在取决于pseudo_slave_mode 系统变量的设置。如果为 false，则服务器拒绝使用 ER_UNSUPPORTED_SQL_MODE 的模式设置。如果pseudo_slave_mode 为真，服务器将忽略不支持的模式并给出警告。请注意，mysqlbinlog 在执行任何 SQL 之前将 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 文件中所需的所有内容

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

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

一切正常。这次它用修改后的sql_mode 转储它

希望对你有帮助。

【参考方案5】：

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

【参考方案6】：

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

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

【参考方案7】：

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

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> SET GLOBAL log_bin_trust_function_creators = 1;

【参考方案8】：

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

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