MySQL超级用户权限到底指哪些？
MySQL中真正具备“超级用户”能力的权限是
SUPER和
SYSTEM_VARIABLES_ADMIN（8.0+）、
SYSTEM_USER_ADMIN（8.0.29+）等组合，但最常被误认为“万能权限”的其实是
ALL PRIVILEGES——它不包含
SUPER，也不能执行关键管理操作。
SUPER允许 kill 线程、修改全局变量、切换 binlog 格式、绕过 max_connections 限制
SYSTEM_VARIABLES_ADMIN替代了 8.0 中部分
SUPER功能，专管动态系统变量
BACKUP_ADMIN和
CLONE_ADMIN是独立权限，不随
ALL自动授予 创建用户、授权、删除用户需要
CREATE USER或
USER_ADMIN，不是
ALL的子集
如何安全地禁用 root@localhost 的 SUPER 权限？
直接
REVOKE SUPER ON *.* FROM 'root'@'localhost';可能导致 mysqld 启动失败或复制中断，尤其当配置了
read_only=ON或启用了 GTID。必须确认依赖项再操作。 先查依赖：
SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('read_only', 'super_read_only', 'enforce_gtid_consistency');
若 super_read_only=ON，必须先
SET GLOBAL super_read_only = OFF;（需当前有
SUPER） 撤销后，用
SHOW GRANTS FOR 'root'@'localhost';确认
SUPER已消失 重启前建议在
my.cnf中显式设置
super_read_only=OFF，避免服务启动时因权限缺失卡住
用最小权限原则替代 root 账户的实操路径
生产环境不该存在长期启用
SUPER的应用账户。应按角色拆分权限，例如备份任务只给
BACKUP_ADMIN+
SELECT，监控账号只给
PROCESS+
REPLICATION CLIENT。 创建专用备份用户：
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'strong_pwd';<br>GRANT BACKUP_ADMIN, SELECT ON *.* TO 'backup_user'@'localhost';<br>GRANT LOCK TABLES ON *.* TO 'backup_user'@'localhost';禁止远程 root 登录：
DELETE FROM mysql.user WHERE User='root' AND Host!='localhost'; FLUSH PRIVILEGES;对 Web 应用账户，明确拒绝高危操作：
REVOKE FILE, SHUTDOWN, SUPER, REPLICATION CLIENT ON *.* FROM 'app_user'@'%';用
mysql_native_password插件替代
caching_sha2_password（旧客户端兼容性好），但密码策略仍需强制长度和复杂度
权限变更后连不上数据库？检查这三处
撤销
SUPER后常见“Access denied”或“Can’t connect”，往往不是权限本身问题，而是配置或会话残留导致。 检查连接是否走 socket（
localhost）还是 TCP（
127.0.0.1）：MySQL 对这两个 host 的权限记录是分开的 确认没有残留
init_connect设置执行了需要
SUPER的语句（如
SET SESSION sql_log_bin=0） 如果用 Docker 或 systemd 启动 MySQL，检查
mysqld.service或
entrypoint.sh是否硬编码了
--skip-grant-tables或
--init-file
实际部署中，
SUPER权限最危险的不是被滥用，而是被遗忘——比如某次临时开通用于调试，之后没人记得回收。只要涉及
GLOBAL变量修改、线程终止、日志控制的操作，都得走审批流程并留审计日志。
