super权限是mysql提权攻击的高危入口，因其可绕过安全限制动态修改全局变量、执行set global、杀线程、加载恶意udf，使普通账号获得root级能力。
为什么SUPER权限是MySQL提权攻击的高危入口
因为SUPER能绕过大多数安全限制：动态修改全局变量（如secure_file_priv）、执行SET GLOBAL、杀掉任意线程、甚至加载恶意UDF。一旦普通账号拿到它，就等同于root操作能力。
常见错误现象：GRANT SUPER ON *.* TO 'appuser'@'%'出现在初始化脚本里；DBA用CREATE USER后顺手GRANT ALL PRIVILEGES，而没意识到ALL PRIVILEGES在MySQL 5.7+默认包含SUPER。
- MySQL 8.0起，
ALL PRIVILEGES不再隐含SUPER，但老版本迁移时容易遗漏检查 -
SUPER无法按库/表粒度收缩，只能全库授予或不授 - 监控日志中出现
SET GLOBAL或INSTALL PLUGIN操作，基本可判定已被滥用
如何精准收回或避免授予SUPER
先查谁有：SELECT user,host FROM mysql.user WHERE Super_priv='Y';。再逐个评估必要性——99%的业务账号根本不需要它。
替代方案优先级从高到低：
- 用
REPLICATION CLIENT代替SUPER查主从状态 - 用
SYSTEM_VARIABLES_ADMIN+PERSIST_RO_VARIABLES_ADMIN（MySQL 8.0.16+）替代部分SET GLOBAL需求 - 文件导入导出改用
LOAD DATA INFILE配合FILE权限，而非放开secure_file_priv - 必须动态调参的场景，改由运维通过配置文件+重启生效，而非运行时
SET GLOBAL
GRANT语句里最容易漏掉的SUPER陷阱
很多人以为只写GRANT SELECT,INSERT ON db.*就安全了，却忽略了两个隐蔽来源：
-
GRANT ALL PRIVILEGES ON *.*—— MySQL 5.7及以前版本会自动带上SUPER -
GRANT PROXY ON 'a'@'%' TO 'b'@'%'+b本身有SUPER，则a可通过代理间接获得 - 复制用户（
REPLICATION SLAVE）在旧版本中常被误配SUPER，其实仅需REPLICATION SLAVE和REPLICATION CLIENT
验证方法：SHOW GRANTS FOR 'user'@'host';，逐条核对输出里是否含SUPER。
MySQL 8.0角色机制怎么帮我们管住SUPER
角色不是银弹，但能切断“权限永久绑定账号”的惯性。把SUPER单独建一个角色，只给DBA临时启用：
CREATE ROLE 'super_admin'; GRANT SUPER ON *.* TO 'super_admin';GRANT 'super_admin' TO 'dba'@'localhost';- DBA需先
SET ROLE 'super_admin';才能执行敏感操作，会话结束自动失效 - 注意：
SET ROLE不能嵌套，且角色不能授予PROXY用户
真正难的是权限回收节奏——很多系统上线后从不清理历史账号，SUPER权限就像灰尘一样越积越多。定期扫描mysql.user表比依赖角色更可靠。
