不能直接用SUPER权限做日常管理，因其具备杀连接、修改全局变量、跳过binlog等高危能力，一旦泄露或误用将导致主从瘫痪、日志清空等致命后果；MySQL 8.0起已弃用SUPER，改用SYSTEM_VARIABLES_ADMIN、RELOAD、CONNECTION_ADMIN等细粒度动态权限替代。
为什么不能直接用SUPER权限做日常管理
SUPER 是 MySQL 旧版中一个“全能型”权限，能绕过很多限制：杀连接、修改全局变量、重载权限表、甚至跳过 binlog 写入。但这也意味着一旦账号泄露或被误授，攻击者或误操作可直接瘫痪主从、清空日志、关闭复制——不是“高危”，而是“一击致命”。MySQL 8.0 起已正式弃用 SUPER，改用细粒度动态权限（Dynamic Privileges）替代。
哪些操作原来依赖SUPER，现在该用什么权限
常见场景和对应替代权限如下：
-
执行
SET GLOBAL修改服务器变量（如max_connections） → 改授SYSTEM_VARIABLES_ADMIN -
运行
FLUSH LOGS或FLUSH STATUS→ 改授RELOAD（注意：RELOAD不再隐含 SUPER 行为，仅限刷新类操作） -
执行
KILL或KILL CONNECTION→ 改授CONNECTION_ADMIN（MySQL 8.0.12+） -
启动/停止复制（
START SLAVE/STOP SLAVE） → 改授REPLICATION_SLAVE_ADMIN -
修改
read_only、super_read_only→ 需同时有SYSTEM_VARIABLES_ADMIN+SESSION_VARIABLES_ADMIN（后者控制会话级变量）
授予权限时容易踩的三个坑
细粒度权限不是“开箱即用”，实操中常因忽略以下细节导致命令失败或权限不生效：
- MySQL 8.0 默认启用
require_row_format和partial_revokes，若用户已有旧权限，新授的细粒度权限可能被隐式拒绝——先运行FLUSH PRIVILEGES，再用SHOW GRANTS FOR 'user'@'host'确认实际生效权限 -
SYSTEM_VARIABLES_ADMIN允许改全局变量，但**不自动赋予读取权限**；想查SELECT @@global.max_connections还得额外给SELECT权限（或SELECTonperformance_schema） - 部分运维脚本硬编码了
SUPER检查逻辑（比如某些备份工具或监控插件），授完新权限后仍报错——要检查工具源码或配置，把权限校验项从'SUPER'改成对应新权限名（如'SYSTEM_VARIABLES_ADMIN'）
一键清理残留SUPER权限的SQL模板
如果数据库里还存在历史账号带 SUPER，建议批量清理。注意：必须用 root 或具备 GRANT OPTION 的账号执行：
SELECT CONCAT('REVOKE SUPER ON *.* FROM ''', user, '''@''', host, ''';')
FROM mysql.user
WHERE Super_priv = 'Y';生成的语句需人工核对后执行。更稳妥的做法是逐个处理：
- 先查出所有带
SUPER的账号：SELECT user, host, Super_priv FROM mysql.user WHERE Super_priv = 'Y'; - 对每个账号，用
REVOKE SUPER ON *.* FROM 'u'@'h';撤销，再用GRANT补上实际需要的细粒度权限 - 最后执行
FLUSH PRIVILEGES;——这步漏掉，权限不会实时生效
细粒度权限本身不难配，难的是理清谁真正需要哪条能力。别为了“省事”留一个 SUPER 账号在生产环境——它不是后门，是敞开的正门。
