SUPER权限是SQL提权的“总钥匙”，因其可动态修改全局变量、加载UDF、重写日志路径等绕过几乎所有安全限制的操作，是攻击者提权的关键分水岭。
为什么SUPER权限是SQL提权的“总钥匙”
MySQL 的 SUPER 权限不是普通管理权，而是绕过几乎所有安全限制的“元权限”。拥有它，就能动态修改全局变量（如 secure_file_priv、general_log_file）、加载UDF、切换SQL模式、甚至重写日志路径写入 /etc/passwd。很多高权限注入场景下，攻击者拿到 root 账号却无法提权，正是因为生产环境已显式回收了 SUPER——这说明它确实是关键分水岭。
检查并回收已有账号的SUPER权限
别只看账号是不是叫 root，重点查它实际有没有 SUPER。执行以下语句确认：
SELECT user, host, super_priv FROM mysql.user WHERE super_priv = 'Y';
对非DBA运维账号，必须立即回收。注意两点：
-
REVOKE SUPER ON *.* FROM 'app_user'@'%';是有效操作，即使该用户原本没被显式授予SUPER，REVOKE也不会报错，但能确保权限状态归零 - 回收后必须执行
FLUSH PRIVILEGES;，否则权限缓存不更新 - 不要用
DROP USER代替REVOKE，否则会连账号一并删除，影响业务连接
创建新账号时默认禁用SUPER且不继承
MySQL 8.0+ 默认创建用户不再带 SUPER，但老版本或迁移脚本常隐式继承。保险做法是显式声明：
CREATE USER 'reporter'@'10.20.%' IDENTIFIED BY 'StrongPass!2026';<br>GRANT SELECT ON sales_db.* TO 'reporter'@'10.20.%';<br>REVOKE SUPER ON *.* FROM 'reporter'@'10.20.%';
特别注意：如果用 GRANT ALL PRIVILEGES，哪怕只在某个库上授权，MySQL 5.7 及以前版本仍可能把 SUPER 一起带上。务必拆解为具体权限（SELECT、INSERT 等），避免模糊授权。
监控SUPER权限变更行为
仅靠初始化配置不够，需防人为误操作或后门账号悄悄启用。MySQL Enterprise Audit 插件可记录 SET GLOBAL 和 GRANT 操作，但社区版不可用。替代方案是启用 general_log 并过滤关键词（仅限临时排查）：
SET GLOBAL general_log = ON;<br>SET GLOBAL log_output = 'table';<br>-- 然后查 mysql.general_log 表中含 'GRANT.*SUPER' 或 'SET.*super' 的记录
更可持续的做法是定期巡检：SELECT user, host FROM mysql.user WHERE super_priv = 'Y' AND user NOT IN ('dba_admin', 'backup_operator'); —— 把合法高危账号名单固化为白名单，其余一律告警。
真正难的不是禁用 SUPER，而是识别哪些业务逻辑“以为自己需要它”。比如某些旧版ORM或监控工具会静默请求 SUPER 来读取状态变量，这时应升级组件而非妥协放权。
