作者：天一閣圖書管理員
今天群里有前同事在問mysqldump出來的sql文件在導(dǎo)入的時(shí)候，報(bào)錯(cuò)error1227（42000）at line 18: Acess denied; you need (at least one of) the SUPER privilege(s) for this operation
定位到18行顯示的是一個(gè)這樣的語句： set @@session.sql_log_bin=0;
按正常情況來說是不會(huì)出現(xiàn)這種情況的兵迅，這個(gè)語句只是控制當(dāng)前session的查詢是否寫入binlog阵子。群里的人都覺得這個(gè)問題很奇怪咆霜。
解決方案1：
大家看到既然是權(quán)限問題，那么就提權(quán)吧盖淡，或者使用root吧。但是前同事說是跳板機(jī)轉(zhuǎn)過去的，沒有辦法用root啦桌，而提權(quán)和授權(quán)(grant)也需要root權(quán)限。方案1被否及皂。
解決方案2：
既然不能用root甫男，只能想其它辦法了，但是我疑惑的是验烧，為什么會(huì)出現(xiàn)用戶無法控制自己的session變量的情況板驳？于是搜索了一下，跳到mysql官網(wǎng)碍拆，找到這樣一段描述：
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有個(gè)bug，無法在子查詢或者事務(wù)中執(zhí)行set @@session.sql_log_bin感混。但是盡信書不如無書端幼，我自己在mysql中執(zhí)行了一下：
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)
說明這個(gè)bug已經(jīng)修復(fù)了，那這個(gè)同事用的mysql版本是不是聲名狼藉的mysql5.6?讓他確認(rèn)了一下弧满，確實(shí)是5.6婆跑。到此問題的根源找到了，解決方法也就有了庭呜。直接刪除sql中所有的set @@session.sql_log_bin語句就可以了滑进。
