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 表中的残留记录。虽然这种情况不常发生，但了解这一点，能在遇到棘手权限问题时，提供一个关键的排查方向。
