需显式授予SUPER权限：CREATE USER后执行GRANT SUPER ON . TO 'user'@'host';FLUSH PRIVILEGES;该权限仅全局生效，不包含在ALL中，MySQL 8.0+中部分功能已被SYSTEM_VARIABLES_ADMIN等细粒度权限替代。
如何创建具备 SUPER 权限的 MySQL 用户
MySQL 的 SUPER 权限不是默认授予的，也不能通过普通 GRANT ALL PRIVILEGES 自动获得。它必须显式声明，且仅对全局生效（即作用域为 *.*）。
常见错误是执行 GRANT ALL ON *.* TO 'admin'@'localhost' 后仍无法执行 KILL、修改 max_connections 或跳过复制等操作——因为 ALL 不包含 SUPER（MySQL 5.7+ 中 ALL 是静态权限集合，不含动态管理类权限）。
- 正确做法：先创建用户，再单独授予
SUPER：CREATE USER 'superadmin'@'localhost' IDENTIFIED BY 'strong_pass';<br>GRANT SUPER ON *.* TO 'superadmin'@'localhost';<br>FLUSH PRIVILEGES;
- 若需更多管理能力，可叠加其他权限，例如：
REPLICATION CLIENT（查看主从状态）、REPLICATION SLAVE（配置从库）、SHUTDOWN（关闭服务） - 注意：MySQL 8.0+ 推荐用角色（
ROLE）管理高权限组合，避免直接赋权给用户；但SUPER本身不能被包含在角色中（直到 8.0.12 才支持角色继承SUPER，且需启用activation_policy）
为什么 root 用户有时也没有 SUPER 权限
MySQL 8.0 默认安装后，root 用户权限取决于初始化方式。使用 mysqld --initialize 生成的 root 密码，默认只拥有 ALL PRIVILEGES（不含 SUPER），尤其在启用了 skip-grant-tables 或通过配置文件绕过权限表时，权限可能被截断。
验证方法：SHOW GRANTS FOR 'root'@'localhost'; —— 若输出中无 GRANT SUPER ON *.*，说明缺失。
- 补救方式（需已有高权限账号登录）：
GRANT SUPER ON *.* TO 'root'@'localhost';<br>FLUSH PRIVILEGES;
- 若连 root 都无法登录，只能停库并以
--skip-grant-tables启动，然后手动更新mysql.global_grants表（MySQL 8.0+）或mysql.user表（5.7 及更早）中的Super_priv字段为Y - MySQL 8.0.16+ 引入了
SYSTEM_VARIABLES_ADMIN和PERSIST_RO_VARIABLES_ADMIN，部分原属SUPER的功能已被拆分，此时即使没SUPER，也可能完成某些系统变量修改
SUPER 权限的实际限制与替代方案
单纯拥有 SUPER 并不意味着能做所有“管理员级”操作。例如：SUPER 允许 KILL 任意线程、修改运行时全局变量、启动/停止复制，但它不能绕过对象级权限检查（如删库仍需 DROP 权限）、不能访问加密密钥、不能读取未授权的表数据。
- 典型受限场景：
– 想用SELECT INTO OUTFILE写文件？需要FILE权限，和SUPER无关
– 想执行CHANGE MASTER TO？除了SUPER，还需REPLICATION SLAVE
– 想修改innodb_buffer_pool_size动态值？MySQL 5.7+ 要求SYSTEM_VARIABLES_ADMIN（SUPER已不覆盖） - 安全建议：生产环境尽量避免长期使用
SUPER用户。可用最小权限组合替代，例如：GRANT REPLICATION CLIENT, PROCESS, SHOW DATABASES ON *.* TO 'monitor'@'%';
比直接给SUPER更可控
MySQL 8.0+ 中 SUPER 权限的兼容性变化
MySQL 8.0 彻底重构了权限系统，SUPER 的语义被大幅收窄。很多过去依赖 SUPER 的操作，现在需要更细粒度的专用权限，且部分操作不再允许动态修改（如 max_connections 在 8.0.3 之后只能在配置文件中设置，运行时 SET GLOBAL 报错 ER_SUPER_PRIV_REQUIRED 却不一定是因为缺 SUPER，而是该变量本身已不可动态改）。
- 关键变动：
–SUPER不再隐含SYSTEM_VARIABLES_ADMIN、SESSION_VARIABLES_ADMIN
–REPLICATION_SLAVE_ADMIN替代了SUPER在复制控制中的大部分能力
– 使用SET PERSIST修改持久化变量，需要PERSIST_RO_VARIABLES_ADMIN - 检查当前会话是否真有某项能力，不要只看
SHOW GRANTS，而要用实际命令测试，比如：SELECT @@global.max_connections;成功不代表能改，SET GLOBAL max_connections = 1000;才是真实检验点
真正难处理的是权限嵌套依赖：一个操作可能同时需要 SUPER + REPLICATION_SLAVE_ADMIN + CONNECTION_ADMIN，漏任何一个都会报看起来毫不相关的错误，比如 ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation —— 这句话里的 “or” 是假的，实际日志里可能显示它偷偷还想要第三个权限。
