MySQL清理过期全局变量权限与撤销SYSTEM_VARIABLES_ADMIN方法

撤销 SYSTEM_VARIABLES_ADMIN 权限后，为什么 SET GLOBAL 仍能执行？

很多管理员会遇到一个困惑：明明已经收回了用户的 SYSTEM_VARIABLES_ADMIN 权限，为什么他还能执行 SET GLOBAL 命令？其实，问题的关键在于，这个权限并非修改全局变量的“唯一钥匙”。

SYSTEM_VARIABLES_ADMIN 主要控制的是“修改动态全局变量”的能力。但MySQL的权限设计要更复杂一些。比如，像 max_connections 这类变量，它的修改还依赖于 CONNECTION_ADMIN 权限（或在旧版本中依赖 SUPER 权限）。更有甚者，部分变量如 sql_mode，允许在会话级别进行修改，这在一定程度上绕过了对全局权限的严格检查。

最需要警惕的一点是：MySQL 并不会因为您撤销了某个权限，就自动将之前通过 SET GLOBAL 修改过的变量值“恢复出厂设置”。权限撤销仅仅是锁上了未来修改的大门，而历史变更造成的影响，依然在系统中持续生效。这就好比收回了某人的仓库钥匙，但仓库里被他之前搬进去的东西，并不会自动消失。

如何确认哪些全局变量已被手动修改过？

那么，如何发现系统中那些“隐藏”的、非默认的变量设置呢？遗憾的是，MySQL 本身并没有内置一个详细的审计日志，来记录“谁在什么时候修改了哪个全局变量”。不过，我们可以通过对比法来识别这些“非默认”状态：

• 首先，查询当前关键变量的值：SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('max_connections', 'wait_timeout', 'innodb_buffer_pool_size');
• 接着，需要找到编译时的默认值作为基准。可以在 MySQL 服务未运行时，执行 mysqld --verbose --help | grep -A 1 "Default options" 来获取。
• 最后，检查配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）中的显式配置。这里需要明确一个优先级顺序：运行时通过 SET GLOBAL 进行的修改优先级最高，会覆盖配置文件中的设置；而配置文件中的设置，又会覆盖编译默认值。

真正“清理”过期修改：必须重启 + 配置文件归位

如果发现了不希望存在的变量修改，该如何彻底清理呢？必须明确一个核心原则：通过 SET GLOBAL 在运行时进行的修改，仅作用于内存，无法通过执行另一条SQL命令来“回滚”或撤销。

唯一可靠的方法，是让 MySQL 服务进程（mysqld）在下次启动时，从“干净”的配置源加载。具体步骤如下：

• 清理配置文件：仔细检查并删除所有在 my.cnf 等配置文件中，因临时调试而写入的变量设置行（例如 max_connections = 500）。
• 确保 [mysqld] 配置段下没有覆盖默认行为的变量定义。
• 重启 MySQL 服务：执行 sudo systemctl restart mysql 或使用相应的启动命令。
• 重启后立即验证：例如执行 SELECT @@global.max_connections;，确认其返回值已恢复为编译默认值（如151），而不是之前手动设置的值。

权限撤销后还需检查用户是否残留其他高危权限

成功执行 REVOKE SYSTEM_VARIABLES_ADMIN ON *.* FROM 'user'@'%'，绝不意味着安全管控已经到位。很多数据库管理员会忽略连带清理其他相关的高危权限：

• 撤销 SUPER 权限：在 MySQL 8.0.12 之后，SUPER 权限被拆分为多个细粒度权限，但遗留的旧账号可能仍然持有它，务必检查并回收：REVOKE SUPER ON *.* FROM 'user'@'%'。
• 检查关联权限：诸如 CONNECTION_ADMIN、PERSIST_ROLES_ADMIN 等权限也可能间接影响变量行为，需要一并审查和撤销。
• 检查角色继承：通过查询 SELECT * FROM mysql.role_edges WHERE TO_HOST = '%'; 来确认目标用户是否通过角色继承获得了隐式的、未意想到的权限。

完成所有权限变更后，一个关键动作是执行 FLUSH PRIVILEGES; 命令，以确保部分变更能够立即生效。

最后，请务必牢记这个最容易被忽略的设计事实：变量值不会随着权限的撤销而自动重置。千万不要以为做了权限回收就万事大吉。现实中，很可能线上系统还在沿用半年前某次深夜调试留下的 SET GLOBAL innodb_log_file_size = 2G 设置，而磁盘空间早已因此发出告警——这才是真正的隐患所在。