MySQL Workbench 8.0导入报错：sql_mode无法设置为NO_AUTO_CREATE_USER

这个问题我之前帮团队同事排查过，核心原因很明确：NO_AUTO_CREATE_USER这个SQL模式在MySQL 8.0版本里已经被彻底移除了，但你的备份文件（大概率是从MySQL 5.7或更早版本导出的）里还包含了设置这个模式的语句，导致导入流程在报错后中断，后面创建存储过程的代码根本没机会执行，所以才会出现只导入了表、存储过程完全缺失的情况。

下面是几种可行的解决方案，你可以根据自己的情况选择：

方案1：修改备份文件后重新导入（最直接） #

如果备份文件不是特别大，直接修改它是最快的办法：

• 先把SQL备份文件（如果是.sql.gz压缩包，先解压）用文本编辑器打开（比如VS Code、Notepad++）
• 搜索包含NO_AUTO_CREATE_USER的行，通常是类似这样的语句：

  SET sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
  

• 把其中的NO_AUTO_CREATE_USER这段内容完全删掉，保存文件
• 重新用MySQL Workbench导入修改后的备份文件，这次应该能完整导入所有表、存储过程和数据

方案2：临时调整会话sql_mode后导入（适合不想修改备份文件的场景） #

如果不想动备份文件，可以先在Workbench里调整当前会话的SQL模式，再执行导入：

1. 打开MySQL Workbench的查询编辑器，连接到目标数据库
2. 先查看当前的sql_mode设置：

   SELECT @@sql_mode;
   

3. 执行语句设置兼容MySQL 8.0的sql_mode（去掉NO_AUTO_CREATE_USER）：

   SET sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';
   

4. 保持这个会话窗口打开，然后通过Workbench的“数据导入/恢复”功能选择你的备份文件，或者直接在查询编辑器里执行：

   SOURCE /你的备份文件路径/backup.sql;
   

方案3：用MySQL 8.0的mysqldump重新导出备份（如果能访问原数据库） #

如果你的备份是从旧版本MySQL导出的，建议直接用MySQL 8.0的mysqldump工具重新导出，它会自动适配8.0的SQL模式，避免这类兼容性问题：

mysqldump -u 你的用户名 -p --all-databases --routines --triggers --events > new_backup.sql

参数说明：

• --routines：确保导出存储过程和自定义函数
• --triggers：导出表关联的触发器
• --events：导出事件调度器（如果有的话）

用这个新生成的备份文件导入，就不会再遇到sql_mode相关的错误了。

额外提醒 #

导入前最好先备份当前数据库的现有数据（如果有的话），避免意外覆盖。另外，MySQL Workbench的导入日志里会明确显示中断的位置，下次遇到类似问题可以先查看日志定位报错点，更快排查问题。

内容的提问来源于stack exchange，提问作者Rajeswari ML