Author: Librarian, Tianyi Pavilion
Today, a former colleague in the group has asked MYSQldump for the SQL file which came out, and sent an error error1227 (42000) at line 18: Acess Denied; you need (at least one of) the SUPER privilege(s) for this operation
Set @@session.sql_log_bin=0; set @@session.sql_log_bin=0;
This does not normally happen. This statement simply controls whether the query in the current session writes to the binlog. Everyone in the group thought it was a strange question.
Solution 1:
you can see that this is a permission issue, so say it, or use root. However, the former colleague said that the skip machine passed over, and there was no way to use root, and the right to lift and grant also required root rights. Option 1 was rejected.
Solution 2:
since you can’t use root, you have to do something else, but I wonder why the user can’t control his or her session variable. So I did a search, went to the mysql website, and found this description:
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 in the Meantime -- in effect, Those transactions are lost.in MySQL5.7, it is not possible to set @session.sql_log_bin within a transaction or subquery. (Bug #53437)
note that the last line says MySQL5.7 has a Bug, Cannot execute set @@session.sql_log_bin in a subquery or transaction. But a book without a book is better than a book without a book. I’ve done it myself in 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)

Now that this bug has been fixed, is this colleague using the infamous version of mysql5.6?Let him confirm that it is 5.6. Once the root of the problem is found, the solution is there. Simply delete all the set @@session.sql_log_bin statements in the SQL.