mysql 8.0.16+中grant super报错error 3715，因super权限已被彻底移除，不再注册为有效权限；必须按实际需求拆解为connection_admin、system_variables_admin等细粒度动态权限显式授予。
GRANT SUPER 为什么直接报错 ERROR 3715
MySQL 8.0.16+ 中 SUPER 已被正式废弃，不是语法写错了，而是权限模型重构的结果。执行 GRANT SUPER ON *.* TO 'user'@'host' 会明确报错：ERROR 3715 (HY000): The 'SUPER' privilege is obsolete and will be removed in a future release。这不是兼容性警告，是硬性拦截——底层已移除该权限的注册逻辑。
哪些操作对应哪个动态权限
不能靠“加个 SUPER 就万事大吉”，必须按实际需求拆解。常见管理动作与对应动态权限如下：
-
KILL CONNECTION 123或KILL QUERY 123→ 需要CONNECTION_ADMIN（注意：PROCESS单独存在时只能看到自己线程，无法 KILL） -
SET GLOBAL max_connections = 200→ 需要SYSTEM_VARIABLES_ADMIN -
SET PERSIST_ONLY innodb_buffer_pool_size = 2147483648→ 需要PERSIST_RO_VARIABLES_ADMIN（且必须配合SYSTEM_VARIABLES_ADMIN才能生效） -
CHANGE MASTER TO ...或START SLAVE→ 需要REPLICATION_SLAVE_ADMIN（REPLICATION CLIENT只能查状态，不等于控制权） -
FLUSH BINARY LOGS→ 需要BINLOG_ADMIN -
BACKUP LOCK或调用mysqlbackup→ 需要BACKUP_ADMIN
授予权限时容易踩的三个坑
动态权限看似细粒度，但实操中极易出错：
- 误以为
GRANT ALL PRIVILEGES ON *.*包含动态权限 —— 实际上ALL PRIVILEGES是静态权限集合，完全不包含任何动态权限（如CONNECTION_ADMIN），必须显式授予 - 忽略 host 精确匹配 —— 动态权限只对
GRANT ... ON *.* TO 'u'@'h'中的'h'生效，'user'@'%'和'user'@'localhost'是两个独立主体，权限不互通 - 混淆
SYSTEM_VARIABLES_ADMIN和SESSION_VARIABLES_ADMIN—— 前者管SET GLOBAL，后者管SET SESSION；若只想限制用户改会话级变量（如wait_timeout），授前者反而过度放权
验证权限是否生效的最简方式
别依赖 SHOW GRANTS 的输出——它默认不显示动态权限。正确验证方法：
- 执行
SHOW GRANTS FOR 'user'@'host'，若没看到动态权限，不代表没授； - 查系统表：
SELECT * FROM mysql.global_grants WHERE USER = 'user' AND HOST = 'host'； - 直接测试目标操作，例如尝试
KILL CONNECTION 1，看是否报ERROR 1227 (42000): Access denied； - 注意：部分云数据库（如阿里云 RDS、PolarDB）会进一步屏蔽某些动态权限（如
BACKUP_ADMIN），即使本地授了也无效
真实环境里，权限不是越全越好，而是越准越稳。一个 CONNECTION_ADMIN 权限配错 host，就可能让监控脚本连不上 kill 自己的异常连接；而多授一个 SYSTEM_VARIABLES_ADMIN，就可能让应用误调高 sort_buffer_size 拖垮整库内存。动态权限的价值不在“替代 SUPER”，而在把“谁能在哪干啥”这件事真正落到每一行 SQL 上。
