mysql导数据遇到错误提示ERROR 1227,Acess denied

最新推荐文章于 2025-06-09 09:07:03 发布

原创最新推荐文章于 2025-06-09 09:07:03 发布 · 4.7w 阅读

CC 4.0 BY-SA版权

本文解决了在使用MySQL 5.6版本时遇到的mysqldump导出的SQL文件在导入过程中报错的问题。该错误提示为error1227（42000）at line 18:Acess denied; you need (at least one of) the SUPER privilege(s) for this operation，具体涉及的SQL语句为set @@session.sql_log_bin=0;。通过分析发现，这是由于MySQL 5.7之前的版本对于该变量的设置需要SUPER权限导致的。最终解决方案为直接删除SQL文件中的所有set@@session.sql_log_bin语句。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

作者：天一阁图书管理员

今天群里有前同事在问mysqldump出来的sql文件在导入的时候，报错error1227（42000）at line 18: Acess denied; you need (at least one of) the SUPER privilege(s) for this operation

定位到18行显示的是一个这样的语句： set @@session.sql_log_bin=0;

按正常情况来说是不会出现这种情况的，这个语句只是控制当前session的查询是否写入binlog。群里的人都觉得这个问题很奇怪。

解决方案1：
大家看到既然是权限问题，那么就提权吧，或者使用root吧。但是前同事说是跳板机转过去的，没有办法用root，而提权和授权(grant)也需要root权限。方案1被否。

解决方案2：
既然不能用root，只能想其它办法了，但是我疑惑的是，为什么会出现用户无法控制自己的session变量的情况？于是搜索了一下，跳到mysql官网，找到这样一段描述：
sql_log_bin
This variable controls whether logging to the binary log is done. The default value is 1 (do logging). To change logging for the current session, change the session value of this variable. The session user must have the [SUPER ](https://dev.mysql.com/doc/refman/5.7/en/privileges-provided.html#priv_super) privilege to set this variable. *Setting this variable to 0 prevents GTIDs from being assigned to transactions in the binary log*. If you are using GTIDs for replication, this means that, even when binary logging is later enabled once again, the GTIDs written into the log from this point do not account for any transactions that occurred in the meantime—in effect, those transactions are lost. In MySQL 5.7, it is not possible to set @@session.sql_log_bin within a transaction or subquery. (Bug #53437)
注意最后一行，上面说MySQL5.7有个bug，无法在子查询或者事务中执行set @@session.sql_log_bin。但是尽信书不如无书，我自己在mysql中执行了一下：

mysql> select version();
+-------------------------+
| version()               |
+-------------------------+
| 5.7.16-0ubuntu0.16.04.1 |
+-------------------------+
1 row in set (0.00 sec)

mysql> set @@session.sql_log_bin=0;
Query OK, 0 rows affected (0.03 sec)

说明这个bug已经修复了，那这个同事用的mysql版本是不是声名狼藉的mysql5.6?让他确认了一下，确实是5.6。到此问题的根源找到了，解决方法也就有了。直接删除sql中所有的set @@session.sql_log_bin语句就可以了。