mysql8.0中如何实现撤销部分全局权限_利用Partial Revokes新特性

MySQL 8.0 的 PARTIAL REVOKES：精细化权限管控的新利器

在数据库权限管理的实践中，管理员常常面临一个核心挑战：如何赋予用户广泛的全局权限，同时又能精准地限制其对特定敏感数据库的访问？例如，允许开发人员查询所有业务数据库，但必须隔离对系统数据库（如 mysql、sys）的访问。在 MySQL 8.0.16 版本之前，这几乎是一个“全有或全无”的二元选择。而 PARTIAL REVOKES（部分撤销）特性的引入，彻底改变了这一局面。它本质上是一种“例外管理”机制，允许管理员在保留用户全局权限的基础上，针对特定数据库施加精确的访问限制。

MySQL 8.0 的 PARTIAL REVOKES 是什么，能撤销哪些权限？

简而言之，PARTIAL REVOKES 并非传统意义上的权限收回，更像是在全局授权之上，叠加了一层精细化的“例外规则”。例如，用户可以继续拥有全局的 SELECT 权限，但管理员可以明确禁止其在 sys 或 mysql 等核心系统库中执行 SELECT 操作。这种设计巧妙地在操作灵活性与系统安全性之间取得了平衡。

然而，这一特性并非适用于所有场景，它有明确的适用范围与限制：

• 权限类型有限：仅适用于部分全局权限，如 GRANT OPTION、CREATE USER、PROCESS、RELOAD、SHOW DATABASES、SHUTDOWN、SUPER、USAGE 等。像 SELECT ON db.* 这类数据库级别的对象权限，本身就不在其管辖范围内。
• 需要手动开启：系统变量 partial_revokes 默认处于 OFF 状态，必须将其设置为 ON 才能启用此功能。此设置重启后不会失效，但建议写入配置文件以实现持久化。
• 存在特定限制：它不支持对 ALL PRIVILEGES 进行部分撤销，也无法处理通过角色（Role）授予的权限。

如何启用并验证 PARTIAL REVOKES 生效？

启用过程非常直接，一条命令即可，无需重启数据库服务：

SET PERSIST partial_revokes = ON;

使用 SET PERSIST 命令的优势在于，它会将设置持久化到 mysqld-auto.cnf 配置文件中，即使 MySQL 实例重启，该配置也不会丢失。如果仅使用 SET GLOBAL，则重启后设置将恢复原状。

启用后，如何验证功能已激活？执行以下查询：

SELECT @@global.partial_revokes;

如果返回值为 1，则表示特性已成功启用。

在实际操作中，可能会遇到两个典型的错误提示，它们恰恰是判断功能状态的重要线索：

• 当出现 ERROR 3790 (HY000): Cannot revoke privileges on *.* from 'u'@'%' because it has partial revokes 时，这意味着该用户身上已经存在部分撤销规则，传统的 REVOKE 命令无法直接清空其全局权限。
• 如果遇到 ERROR 3789 (HY000): Partial revokes are disabled，则明确表示你忘记将 partial_revokes 系统变量设置为 ON 了。

怎么给用户加一条“禁止查 sys 库”的部分撤销？

语法非常直观：REVOKE ... ON database.* FROM user。这里的关键在于，目标范围必须是 database.*（数据库级别），既不是全局的 *.*，也不是更细粒度的 database.table（表级别）。

假设我们需要禁止用户 'appuser'@'%' 查询 sys 系统库，命令如下：

REVOKE SELECT ON sys.* FROM 'appuser'@'%';

这条命令执行后，appuser 对其他业务库（例如 myapp）的 SELECT 权限完全不受影响，其全局 SELECT 权限本身也依然存在。它只是新增了一条针对 sys 库的例外拒绝规则。

想查看实际效果？查看用户权限：

SHOW GRANTS FOR 'appuser'@'%';

你会在输出结果中清晰地看到这样一行记录，这正是部分撤销规则的体现：

REVOKE SELECT ON `sys`.* FROM `appuser`@`%`

有几点需要特别注意：

• 目标必须明确：撤销权限的目标数据库必须是一个已存在的、具体的库名，不能使用通配符模式（例如 `test_%`.* 是不被允许的）。
• 操作禁区：INFORMATION_SCHEMA 数据库被明确禁止施加部分撤销。
• 效果立竿见影：如果用户拥有 SELECT ON *.* 全局权限，同时又增加了 REVOKE SELECT ON sys.* 规则，那么当他尝试查询 sys 库中的任何表时，都会立刻收到 ERROR 1142 (42000): SELECT command denied to user 的错误提示。

部分撤销和普通授权混用时，权限怎么算？

当多种权限规则并存时，MySQL 遵循一个明确的优先级顺序：显式拒绝 > 显式授权 > 隐式拒绝。这意味着，一条 REVOKE SELECT ON sys.*（显式拒绝）的效力，会高于 GRANT SELECT ON *.*（显式授权）。

通过以下几个典型场景，可以更深刻地理解其计算逻辑：

• 用户先被授予 GRANT SELECT ON *.*，再被施加 REVOKE SELECT ON sys.*。最终结果是：查询 sys 库报错，查询其他所有库畅通无阻。
• 用户拥有 GRANT SELECT ON myapp.*，此时想通过 REVOKE SELECT ON myapp.t1 来限制单张表？抱歉，这行不通。 因为部分撤销的粒度只到数据库级别，不支持表级撤销。
• 用户被授予了 GRANT ALL ON *.*，然后执行 REVOKE PROCESS ON *.*。这是有效的，PROCESS 权限会被移除。同时，如果再执行 REVOKE SELECT ON sys.*，这条规则也同样生效，两者互不冲突。

最后，有一个极易被忽略的“坑”需要警惕：一旦为用户添加了部分撤销规则，就不能简单地通过 DROP USER 来彻底清理其所有权限痕迹。在某些极少数情况下，尤其是在版本升级或数据迁移时，可能需要手动清理 mysql.role_edges 和 mysql.default_roles 表中的残留记录。虽然这种情况不常发生，但了解这一点，能在遇到棘手权限问题时，提供一个关键的排查方向。