不能。MySQL 5.7 中撤销 SUPER 即可阻止 SET GLOBAL；MySQL 8.0+ 必须显式撤销 SYSTEM_VARIABLES_ADMIN（global）、SESSION_VARIABLES_ADMIN（session）和 PERSIST_RO_VARIABLES_ADMIN（PERSIST），仅 revoke SUPER 无效。
撤销 SUPER 权限后仍能改 global 变量？
不能。MySQL 中修改全局变量（如 SET GLOBAL sort_buffer_size = 4194304）必须拥有 SUPER 权限（MySQL 5.7）或 SYSTEM_VARIABLES_ADMIN + SESSION_VARIABLES_ADMIN（MySQL 8.0+）。但仅撤销 SUPER 不够——8.0 之后权限拆分了，旧逻辑会失效。
- MySQL 5.7：撤掉
SUPER即可阻断SET GLOBAL - MySQL 8.0+：必须显式撤销
SYSTEM_VARIABLES_ADMIN（控制 global）和SESSION_VARIABLES_ADMIN（控制 session），SUPER已被弃用但向后兼容，不撤销它可能留后门 - 注意：
SET PERSIST和SET PERSIST_ONLY还需额外的PERSIST_RO_VARIABLES_ADMIN权限，否则报错Access denied; you need (at least one of) the PERSIST_RO_VARIABLES_ADMIN privilege(s) for this operation
如何精准回收变量修改权限（8.0+）
直接用 REVOKE 撤销对应权限，不要依赖 SUPER 的“一揽子”效果。权限名必须拼写准确，大小写敏感。
- 禁止改 global：
REVOKE SYSTEM_VARIABLES_ADMIN ON *.* FROM 'user'@'host'; - 禁止改 session（含
SET SESSION）：REVOKE SESSION_VARIABLES_ADMIN ON *.* FROM 'user'@'host'; - 禁止写入 mysqld-auto.cnf（即禁用
SET PERSIST）：REVOKE PERSIST_RO_VARIABLES_ADMIN ON *.* FROM 'user'@'host'; - 执行后必须
FLUSH PRIVILEGES;，否则权限变更不生效
常见误操作：只 revoke SUPER，没查实际权限
用户可能以为 REVOKE SUPER ON *.* FROM ... 就万事大吉，但 MySQL 8.0 默认给新用户分配了细粒度权限，SUPER 只是别名。真正起效的是底层权限位。
- 查当前用户真实权限：
SHOW GRANTS FOR 'user'@'host';，确认输出里没有SYSTEM_VARIABLES_ADMIN - 如果看到
GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO ...，说明SUPER撤了但细粒度权限还在 - 不要用
DROP USER再重建来“重置权限”，容易丢其他授权，直接REVOKE更安全
权限回收后仍能改某些变量？检查变量作用域和只读性
不是所有全局变量都能被普通用户修改，有些本身就是只读（read_only=ON 时连 super 用户也不能改），有些则依赖引擎状态（如 innodb_buffer_pool_size 在运行中不可调）。但关键点在于：权限控制的是“能否发起 SET GLOBAL 请求”，不控制“请求是否成功”。
-
max_connections、wait_timeout等动态 global 变量：权限到位后，无权限用户执行SET GLOBAL会直接报错ERROR 1227 (42501): Access denied; you need (at least one of) the SYSTEM_VARIABLES_ADMIN privilege(s) for this operation -
innodb_log_file_size这类只读变量：即使有权限，也会报Variable 'innodb_log_file_size' is a read only variable - 验证方式：用目标用户登录，执行
SET GLOBAL sort_buffer_size = 1048576;，看是否报权限错，而非只测能不能设成某个值
最易被忽略的是 MySQL 版本差异带来的权限语义变化——同一句 REVOKE SUPER，在 5.7 和 8.0 下实际拦截效果不同。务必按版本查 SHOW GRANTS 确认真实持有的权限项。
