revoke super on . 不能立即生效，因mysql仅在连接建立时检查全局权限，活跃连接仍保留原super能力；8.0.16+直接报错error 3715，须改用system_variables_admin等细粒度权限替代。
为什么REVOKE SUPER ON *.* 不能立刻让高危操作失效
因为MySQL只在连接建立时检查全局权限，已存在的活跃连接（包括应用长连接、DBA客户端会话）仍保留原SUPER能力。执行REVOKE SUPER ON *.* FROM 'user'@'%'后，KILL、SET GLOBAL、CHANGE MASTER TO等命令在旧连接里照常运行。
必须主动干预：
- 查活跃会话：
SELECT ID, USER, HOST, COMMAND, TIME FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'user'; - 逐个
KILL [ID]或批量KILL CONNECTION - 让应用重启连接池，或客户端手动重连
FLUSH PRIVILEGES对动态权限变更无效，8.0+中也不再必要。
MySQL 8.0.16+ 执行REVOKE SUPER直接报错ERROR 3715
这不是语法或权限表问题，而是MySQL主动废弃了SUPER语义。版本≥8.0.16时，REVOKE SUPER ON *.* FROM ...必然触发ERROR 3715 (HY000): The SUPER privilege is obsolete。
必须改用细粒度权限替代：
-
SYSTEM_VARIABLES_ADMIN→ 替代SET GLOBAL -
CONNECTION_ADMIN→ 替代KILL其他连接 -
REPLICATION_APPLIER_ADMIN→ 替代从库线程控制 -
SHUTDOWN→ 替代关闭实例
查当前支持的动态权限：SHOW PRIVILEGES;；回收示例：REVOKE SYSTEM_VARIABLES_ADMIN, CONNECTION_ADMIN ON *.* FROM 'user'@'%';
误授SUPER后无法彻底撤回：角色继承和隐式依赖
用户可能不是直接被授予SUPER，而是通过角色间接获得——比如GRANT SUPER ON *.* TO 'dba_role'; GRANT 'dba_role' TO 'user'@'%';。此时只对用户执行REVOKE毫无作用。
还要注意隐式依赖：
- 若启用了
super_read_only=ON，撤销SUPER会导致mysqld启动失败 - GTID复制环境下，
SUPER是RESET MASTER、SET GTID_PURGED的前提 - 某些备份工具（如Percona XtraBackup）内部调用
FLUSH TABLES WITH READ LOCK，依赖LOCK TABLES而非SUPER，但错误地授SUPER反而掩盖了真正缺失的权限
导入SQL文件报ERROR 1227，授SUPER是典型误解
报错ERROR 1227 (42000): Access denied; you need SUPER privilege，99%不是权限不足，而是SQL文件里写了普通用户无权执行的语句：
-
SET @@GLOBAL.GTID_PURGED=...（mysqldump默认开启GTID时生成） -
DEFINER=root@localhost（视图/函数定义中的definer） -
RESET MASTER、CHANGE MASTER TO等复制命令
正确做法是清理SQL文件，而不是授SUPER：
去GTID行：sed -e '/GTID_PURGED/d' dump.sql > clean.sql
抹DEFINER：sed -e 's/DEFINER[[:space:]]*=[[:space:]]*[^*]*\*/\*/g' clean.sql > final.sql
导出时预防：mysqldump -u root -p --set-gtid-purged=OFF --single-transaction db_name > dump.sql
云数据库（RDS/CDB）通常禁用SUPER，授了也白授；而SUPER一旦开放，用户就能KILL任意连接、篡改max_connections，风险远大于问题本身。
