作者：天一阁图书管理员
今天群里有前同事在问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语句就可以了。
